WHATWG Weekly: Return of the Layout Table
This is my last WHATWG Weekly for a while. Shelley Powers will take over starting next week. Meanwhile my friend (and colleague these days) Karl Dubost has started writing similar summaries for the W3C Blog: Open Web Platform Weekly Summary. Hopefully this is just the beginning.
EventSource, Workers, and Progress Events
The W3C WebApps Working Group published three Last Call Working Drafts: Server-Sent Events (EventSource), Web Workers, and Progress Events. In theory Last Call is the final check before a specification is more or less done. In practice it can still take over seven years. Irrespective of theory and practice, the sooner you submit your comments on a specification the better. Specifications are implemented, then become used, and at some point become immutable in areas you might be displeased with. You want to beat that.
A restrictive datalist, inline lists, cross-origin databases, and drawWindow()
Over on the WHATWG mailing list Markus Ernst brought up restricting the color palette for the <input type=color> control. Using the datalist element you can suggest a palette, but you cannot restrict it any way. This discussion quickly generalized to all new controls as they have a similar limitation. Jonas Sicking pointed out that providing a good user interface might be difficult. I said that we should probably wait a bit until the existing functionality is implemented by most user agents before adding yet more features.
Jukka K. Korpela re-raised the question many have had since they learned HTML: What about paragraphs that contain lists? James Graham pointed out that the section element cannot be used. Markus Ernst suggested we introduce a new inline list element. Probably best to just not worry too much about it and carry on as we have done for the past decade.
Apart from markup, there were a few API requests too. Brett Zamir wants cross-origin databases. Erik Möller (with Opera) asked about making Mozilla’s <canvas>.drawWindow() part of the web platform.
Layout tables
The W3C HTML Working Group decided that when you put role=presentation on a table element it can be used (in a conforming way) for presentational purposes.
I would love to see CORS to be implemented in the EventSource specification so we can create a real time read only stream of data..
I tried to submit this through the feedback form but it seems to be broken as it’s complaining about JavaScript that needs to be enabled.. ( Which is enabled )
The layout table attribute is the most lame of the lamest ideas I’ve ever seen come out of this group.
@Rob, what is lame is that developers regularly resort to using layout tables to acheive the design/functionality they require. Check out their use on the google home page for example. I did not support the change and the paving of the cowpath – instead of ‘Tables MUST NOT be used as layout aids’ HTML5 will now specify ‘Tables SHOULD NOT be used as layout aids’. I was surprised it was accepted. But can understand the reasoning that discouraging developers while providing them with a repair technique in such situations is better than just saying no.
The HTML5 spec implicitly condones a lot of dodgy practices (i think), as i recently realised, there is not (to my knowledge) a single MUST requirement on browsers to implement the features of HTML5 in an accessible, interoperable way. Once you start scratching the surface of the accessibility implementation, it is apparent that there are lots of issues that are not addressed or even mentioned in the HTML5 spec.
Speaking about progress bars. Is there standard way to set foreground color of those yet?
Why inline lists? And why still differentiate HTML elements by one of their CSS standard properties at all?
Renaming the role to “presentation_deprecated” would be nice, to make people feel guilty using it. (Also making a statement as not endorsing it).
@steve_faulkner I am not sure how often the code changes on the Google homepage, but the currently do not use tables.
Concerning the table decision…
Philosophically, I agree – Tables should never be used for layout. HTML is (ideally) a data description language, CSS is (ideally) the presentation language.
That being said – I HAVE used tables for layout. Especially when laying out a form. The reason is because I need both horizontal and vertical alignment. I would love to be corrected on this, but I believe CSS only allows for either a horizontal alignment (via float’s), or a vertical alignment (via the normal display: block).
Imagine you have a form, with fields like:
Name: [text input]
E-mail: [text input]
Web: [text input]
etc…
How do you ensure that the text inputs line up vertically, but also that they are always aligned next to the label… without using tables?
Due to the varying length of the labels (“Name:”, “E-mail:”), the text inputs will be jagged. You need a table to force the horizontal and vertical alignment.
Please note that if you try to “cheat” using floats, you risk something like this:
Name: [text input]
E- [text input]
mail: [text input]
Web:
@leroy just looked at google.com using firefox 3.6 on windows http://twitpic.com/4bbf6r firebug html panel shows table code. There is more when viewed in internet explorer 9 as there is an advert for chrome displayed that also use tables for layout.