Re: [whatwg] alternate ids for elements
On 3 December 2014 at 14:15, Julian Reschke julian.resc...@gmx.de wrote: 2.) You may want to support anchors based on section numbers which will allow other parties to link to a specific section of the document while only knowing the section number and a template (think references to sections numbers in RFCs over on tools.ietf.org). another way to do this is let people link to parts of a document based on CSS selectors rather than author-defined IDs. One such proposal is http://simonstl.com/articles/cssFragID.html, whereby you could link to -say- the fifth h2 using http://example.com/lorem.html#css(h2:nth-of-tyupe(5)), whether or not the author had put an ID on the h2. bruce
Re: [whatwg] Why do we have input type='month' and input type='week'?
On Wed, 30 Jan 2013 20:55:29 -, Mounir Lamouri mou...@lamouri.fr
wrote:
Regarding 'month', I mostly don't understand the use case. I can't find
any situation where I am asked to input a { month, year } information.
Given that the element is pretty trivial to implement by authors (this
is basically two select or a select and a input type='number'),
Others have commented on use-cases for collecting month, eg credit card
expiries.
The use-case for an input type I imagine is that a browser can have a
select-like UI (Jan, Feb, March, April ...) which, in a French language
browser becomes Janvier, Fevrier, Mars, Avril .. (or even Vendémiaire
to Fructidor for FRC fans).
b
Re: [whatwg] use of article to markup comments
On Sat, 26 Jan 2013 10:56:10 -, Steve Faulkner faulkner.st...@gmail.com wrote: Lists are appropriate for indicating nested tree structures. The use of lists to markup comments is a common mark up pattern used in blogging software such as wordpress. The code verbosity is not dissimilar to the use of article, less so even option end /li tags are omitted. Besides comments are generated code not hand authored so I don't see a problem with code verbosity [...] (It makes some sense, I suppose, to think of comments as a list, but *unordered*? If you're going to group them at all, wouldn't the order be important? Bruce Lawson ( http://lists.w3.org/Archives/Public/public-html/2013Jan/0111.html)'s observation that comments are heavily dependent on context would seem to support the idea that it *is* important, especially since some comments are responses to others.) agreed it would be better to use order lists. Wordpress blogs, for example, have comments like Bob Smith said at a href=#permalink9.55 on 31 Febtember/a: LOL Thus, every comment has a link that a UA can use to jump from comment to comment. The order is implied via the timestamp. So what's wrong with article h1Witty blogpost/h1 plorem ipsum section h235 erudite and well-reasoned comments/h2 divBob Smith said at a href=#permalink19.55 on 31 Febtember/a: Can I use DRM in Polyglot documents?/div divHixie said at a href=#permalink29.57 on 1 June/a: What's your use case?/div ... /section /article In short, why should the spec suggest any specific method of marking up comments? -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] Forms-related feedback
On Wed, 16 Jan 2013 11:01:14 -, Tab Atkins Jr. jackalm...@gmail.com wrote: Strongly agree. I think any arguments that sites will refuse to use the native controls because they don't match the site's theme are countered by the observation that most sites using JS-library equivalents today still don't theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library. Anecdotal, but *literally* every time I've given talks or demos of the new form input types I've been asked how they can be styled, and many devs have told me they'll continue to use things like jQuery UI because of the number of themes http://jqueryui.com/themeroller/ (which makes me sad) -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] Forms-related feedback
On Wed, 16 Jan 2013 13:48:43 -, Bronislav Klučka bronislav.klu...@bauglir.com wrote: 3/ Way for styling native controls are pseudo-classes, the fact, that we do not have those yet is hardly reason for abandoning it. We would have no progress at all if we had dropped every technology that is not perfect for everyone/everytime. The fact, that there is no way for styling is not a reason for abandoning/refusin, but a reson to create such pseudo-classes and implementing them. miscommunication: I strongly agree with you. I'm arguing for an urgent need to create the mechanism for styling the html controls, not for the abandonment of them. Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] use cases for untitled article and section elements
On Tue, 15 Jan 2013 09:57:45 -, Steve Faulkner faulkner.st...@gmail.com wrote: Can anyone point me to or provide use cases for untitled article and section elements? those in which the heading is to be injected via script -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] use cases for untitled article and section elements
On Tue, 15 Jan 2013 12:59:01 -, Steve Faulkner faulkner.st...@gmail.com wrote: bruce wrote: Can anyone point me to or provide use cases for untitled article and section elements? those in which the heading is to be injected via script Ok so in a a rendered page or outline? I don't understand the question sorry -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] use cases for untitled article and section elements
On Tue, 15 Jan 2013 13:44:44 -, Steve Faulkner faulkner.st...@gmail.com wrote: what is the use of the untitled articles? or of the 133 untitled articles on http://html5doctor.com/designing-a-blog-with-html5/ what is the use case for using article in this case over the use of other markup such as lists? I can't answer for other doctors, but I see no advantage there (although I see no advantage to using lists, either). On my own blog, which also uses article for comments, I'm considering changing it from article comment by Fred on 12 Dec at 4.52 divcomment text/div /article into article h3Fred said on 12 Dec at 4.52/h3 divcomment text/div /article so there are are headings by which comments may be navigated, -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] use cases for untitled article and section elements
On Tue, 15 Jan 2013 15:08:33 -, Cory Sand yrocs...@gmail.com wrote: Hi, can I ask the purpose of the div in marking up the comment text? Is it just for styling/positioning? yes. -- Bruce Lawson Open standards evangelist Developer Relations Team Opera http://dev.opera.com
Re: [whatwg] Correcting some misconceptions about Responsive Images
On Fri, 18 May 2012 01:16:52 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: I believe the CG rules would not allow an employee of a W3C Member company to be a free agent though. It appears not. I tried to join the responsive images CG as just me as I'm interested, but not representing Opera, and don't like to give people the impression that my interest or support of any suggestion means Opera will implement it next Thursday. But I couldn't; I had to join as an Opera rep, and get permission internally. That's time-consuming and process laden.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... img src=face-600-200 at 1.jpeg alt= srcset=face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... I'd like to see media-queries extended to support bandwidth, svg etc., then we give developers the option to detected features and choose media types appropriately. The 600w 200h bit can be directly translated into a media query - it's equivalent to (max-width: 600px) and (max-height: 200px). It's collapsed into a custom syntax for terseness. Just so I understand 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't media queried because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current Bruce's bedroom WiFi I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet. Is that accurate? I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. bruce-speaking-for-myself-not-Opera
Re: [whatwg] di? Please?
On Tue, 10 Jan 2012 07:32:35 -, Hugh Guiney hugh.gui...@gmail.com wrote: As I understand it, the main reason for rejecting di was that it solves a problem that is allegedly CSS's job, but as an author who uses dls quite extensively, adding a grouping element would really make my life a lot easier. Yes, my most common problem with dls is styling them, but it's hardly CSS's fault. What kind of styling am I attempting to do? Mostly, to arrange them in columns. [...] Simply put: just because the parsing algorithm is well-defined and we can imply association sans-container, that doesn't mean authors (like myself) won't want finer-grained control over grouping. Seems to me no need to add a new element. If div could be a child of dl then you could use that. However, it can't. I don't know why, though. bruce
[whatwg] Editorial comment r/e summary element
Fair dames and damsels of the list Consider http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-summary-element: The summary element represents a summary, caption, or legend for the rest of the contents of the summary element's parent details element, if any. I read if any to mean there may or may not be a summary, caption or legend. However, a questioner to HTML5 Doctor believes that summary can be used outside details, reading if any to sugest that there may not be a summary element's parent details element. (She wants to use summary at the top of an article to summarise its contents, because the ambiguous prose I quote suggests that a parent details element is optional). Can we remove this ambiguity? The summary element represents an optional summary, caption, or legend for the rest of the contents of the summary element's parent details element would work. bruce -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [whatwg] details for long description of image/ video etc
On Sat, 02 Apr 2011 18:40:30 +0100, John Foliot fol...@wats.ca wrote: One of the largest problems with longdesc is/was that HTML4 did not clearly articulate how user-agents should interact with the attribute (expectations), so browsers did nothing. Let's learn from our earlier mistakes. Tangent, but I think longdesc is reasonably articulated in the HTML4 spec (given it's not a spec with the same rigour that we now expect): This attribute specifies a link to a long description of the image. This description should supplement the short description provided using the alt attribute. When the image has an associated image map, this attribute should provide information about the image map's contents. This is particularly important for server-side image maps. Since an IMG element may be within the content of an A element, the user agent's mechanism in the user interface for accessing the longdesc resource of the former must be different than the mechanism for accessing the href resource of the latter. Whatever the reasons behind non-Opera browsers' decision not to implement longdesc, I don't think that the spec is a major one (but obviously I don't know as I didn't take those decisions). It would have been counter-productive to specify longdesc must be activated by choosing an option from a contextual menu because not every UA has a contextual menu. Or Superwhizzo browser might decide that it wishes to XHR the longdesc URL in and display it on longclick rather than the contextual menu. Tangent end. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel Buy my HTML5 book www.introducinghtml5.com
[whatwg] details for long description of image/ video etc
From a comment in a blog post of mine about longdesc (http://www.brucelawson.co.uk/2011/longdesc-in-html5/comment-page-1/#comment-749853) I'm wondering if this is an appropriate used of details details summary img src=chart.png alt=Graph of percentage of total U.S. non-institutionalized population age 16-64 declaring one or more disabilities /summary pThe bar graph shows the percentage of total U.S. noninsitutionalized population age 16-64 declaring one or more disabilities. The percentage value for each category is as follows:/p ul liTotal declaring one or more disabilities: 18.6 percent /li liSensory (visual and hearing): 2.3 percent/li liPhysical: 6.2 percent/li liMental: 3.8 percent/li liSelf-care: 1.8 percent/li liDiffuculty going outside the home: 6.4 percent/li liEmployment disability: 11.9 percent/li /ul pdata retrieved from a href=http://www.census.gov/prod/2003pubs/c2kbr-17.pdf; title=Link to External Site class=external2000 U.S. Censusspan - external link/span/a/p /details .. thereby acting as a discoverable-by-anyone longdesc. (The example is adapted from the longdesc example at http://webaim.org/techniques/images/longdesc#longdesc) Note to grumpy people: I'm not trying to advocate abolishing longdesc, just seeeing whether details can be used as an alternative.
Re: [whatwg] Timed tracks: feedback compendium
On Sat, 25 Dec 2010 06:39:02 -, Ian Hickson i...@hixie.ch wrote: [...] On Fri, 5 Nov 2010, Bruce Lawson wrote: http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#sourcing-in-band-timed-tracks says to create TimedTrack objects etc for in-band tracks which are then exposed in the API - so captions/subtitles etc that are contained in the media container file are exposed, as well as those tracks pointed to by the track element. But http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#timed-track-api implies that the array is only of tracks in the track element: media . tracks . length Returns the number of timed tracks associated with the media element (e.g. from track elements). This is the number of timed tracks in the media element's list of timed tracks. I don't understand why you interpret this as implying anything about the track element. Are you interpreting e.g. as i.e.? Suggestion: amend to say Returns the number of timed tracks associated with the media element (e.g. from track elements and any in-band track files inside the media container file) or some such. I'd rather avoid talking about the in-band ones here, in part because I think it's likely to confuse authors at least as much as help them, and in part because the terminology around in-band timed tracks is a little unclear to me and so I'd rather not talk about them in informative text. :-) If you disagree, though, let me know. I can find a way to make it work. I disagree, but not aggressively vehemently. My confusion was conflating track elements with the three instances of the phrase timed tracks in close proximity. I suggest that Returns the number of timed tracks associated with the media element (i.e. from track elements and any packaged along with the media in its container file) would be clearer and avoid use of the confusing phrase in-band tracks.
[whatwg] ambiguity in timed tracks API part of spec?
http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#sourcing-in-band-timed-tracks says to create TimedTrack objects etc for in-band tracks which are then exposed in the API - so captions/ subtitles etc that are contained in the media container file are exposed, as well as those tracks pointed to by the track element. But http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#timed-track-api implies that the array is only of tracks in the track element: media . tracks . length Returns the number of timed tracks associated with the media element (e.g. from track elements). This is the number of timed tracks in the media element's list of timed tracks. Suggestion: amend to say Returns the number of timed tracks associated with the media element (e.g. from track elements and any in-band track files inside the media container file) or some such. Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel Buy my HTML5 book www.introducinghtml5.com
Re: [whatwg] Type Date
On Thu, 06 May 2010 23:36:00 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: My suggestion was to fall back to using a standard text input field and use JavaScript to add the date picker which will allow the user to enter the date manually if so desired. Are there any current plans to add this ability to type=date or is the fallback the best option? That's a browser UI issue, then. File a bug on Opera suggesting that. FYI, confirming I've filed a bug on that already. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel Pre-order my HTML5 book www.introducinghtml5.com
[whatwg] confusion between article and summary; editorial change suggestion
The definition for article says The article element represents a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication. This suggests that if you have a self-contained composition that you do not intend to be distributable via syndication, you shouldn't use article. Section says Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element - here, the intent of syndication is diluted into it would make sense to syndicate the content. I suggest that article be amended to say something similar, eg The article element represents a self-contained composition in a document, page, application, or site which would make sense if independently distributed or reused, e.g. in syndication. so that the two mentions of article match, especially given that Jeremy Keith has reported confusion between article and summary. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
[whatwg] Why are form fields without a name barred from constraint validation?
Constraint validation: If an element does not have a name attribute specified, or its name attribute's value is the empty string, then it is barred from constraint validation. http://dev.w3.org/html5/spec/forms.html#naming-form-controls As a matter of interest, why? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
Re: [whatwg] Why are form fields without a name barred from constraint validation?
On Fri, 02 Apr 2010 09:28:50 -, Futomi Hatano i...@html5.jp wrote: Because such controls are ignored when the form is submitted. http://dev.w3.org/html5/spec/forms.html#form-submission-algorithm Nameless controls are meaningless in form submission. So, those controls do not need to be validated, I think. Thanks! b
Re: [whatwg] Use of p element inside the blockquote element
On Mon, 01 Mar 2010 15:59:39 -, Rimantas Liubertas riman...@gmail.com wrote: Previously in HTML 4.0 Strict and XHTML 1.0 Strict, any content inside Or, maybe a one-line explanation stating that the previous requirement of the blockquote element re. content being contained in a p, has now been loosened up. It is implied by content model for the element, I am not sure if more explict explanation is needed. Maybe no explicit explanation is required, but people pay almost exegesis-like attention to code samples in specs, so I agree with Phil that it would be good to have one bare text example in the spec -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
[whatwg] Qs about details element
Hi Couple of questions about the details element, raised by Shelley Powers in comments to an article I wrote on html5 doctor http://html5doctor.com/summary-figcaption-element/ 1) I read that details doesn't require any authorial scritping to work, and that a details element should expand/ contract for user agents that have JS disabled. Is that correct? 2) What should UAs do when printing? It seems to me that, when printing, a details element should be open, regardless of the state of the boolean open attribute. (because it's a markup attribute, there is presumably now way for a print stylesheet to override this). Can that be added to the spec? -- Bruce Lawson www.brucelawson.co.uk - sent from my ZX80
Re: [whatwg] Question about header and footer
On Tue, 12 Jan 2010 09:19:04 -, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Bruce Lawson wrote: Is it permissible for one element to have more than one child headers, or more than one child footers? Yes. And, if is permissible, should it be? Unless we have a very good reason, I don't think we should start placing arbitrary restrictions on how elements can be used. In fact, there's a very good reason to allow footers to be used more than once per section, as illustrated by the first footer element example in the spec. I don't believe it's a problem for multiple headers either as the sectioning algorithm will create implied sections from the headings anyway. Makes sense. Thanks Lachy. b -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
[whatwg] Question about header and footer
Is it permissible for one element to have more than one child headers, or more than one child footers? And, if is permissible, should it be? Bruce Lawson www.brucelawson.co.uk - sent from my ZX80
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Fri, 02 Oct 2009 23:51:55 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: the use-case for figure and details are sorta minimal anyway - it's enough that they can justify themselves, but just barely. Use case for figure is perhaps minimal. But details is hugely useful. It's an incredibly common thing to want to collapse and hide a section of explanatory text. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, 29 Sep 2009 20:53:44 +0100, Dean Edwards dean.edwa...@gmail.com wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) Or even just one for both: rubric anyone? b -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
Re: [whatwg] article/section/details naming/definition problems
On Wed, 23 Sep 2009 13:55:50 +0100, Ian Hickson i...@hixie.ch wrote: A widget. Although the spec specifically mentions widgets that can be reused, I haven't been able to find any use cases of this yet. I don't that article is an element name that readily springs to mind for developers publishing widgets. The widgets on iGoogle are an example. [snip] * The use case of marking up application widgets with article stretches the definition and makes it hard to come up with a good criteria for article. I think it's the same concept -- a self-contained blob of reusable content. Oops. I'd just said on html5 doctor that I would mark those up with section. http://html5doctor.com/the-section-element/comment-page-1/#comment-1107 Each widget might be re-usable, but is it (coining new word:) syndicatable? Are re-usable and syndicatable synonymous? b
Re: [whatwg] article/section/details naming/definition problems
On Wed, 16 Sep 2009 12:28:36 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 16 Sep 2009, Bruce Lawson wrote: Seems to me that (current) sections aren't for syndicating (tabs, chapters etc), while blog posts (currently articles) *are* for potential syndication (although the cite attribute was recently removed from article). I've adjusted the spec's definition more in line with this. Groovy. A comment in an article is also marked up as article, but is unlikely to be a candidate for syndication as it's out of context. Is this correct? As James on IRC pointed out: http://intertwingly.net/blog/comments.html http://firehose.diveintomark.org/ http://www.zeldman.com/comments/feed/ Also, consider Twitter, Reddit, most forums, etc, where individual comments are definitely syndicated. Yup. Makes sense to me.
Re: [whatwg] small element should allow nested elements
On Fri, 07 Aug 2009 14:19:23 +0100, Remy Sharp r...@leftlogic.com wrote: Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. I suggested it in the w3c list, not this one. Link: http://lists.w3.org/Archives/Public/public-html/2009Jan/0130.html ... When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed Previously we got on a bit of a navelgaze about what constitutes legalese/ disclaimers and whether any sites actually use it. But given that browsers currently allow small to go round block level elements, I agree with Remy that we should document the current state of browsers and allow the element to be both inline and block, like a, ins and del. bruce
Re: [whatwg] Dates BCE
On Thu, 30 Jul 2009 15:05:10 +0100, Sam Kuper sam.ku...@uclmail.net wrote: I sure hope there are! Historians and classicists are increasingly publishing to the web, and being unable to mark up years BCE in HTML 5 would hinder this. That said, marking up a year, say 1992 AD, (as opposed to a specific day within a specific month within a specific year, e.g. 3rd September 1992) also seems to be hard or impossible in HTML 5... unless I've misread the spec. Orthodoxy has it that there is no use case for marking up an ancient date or fuzzy date like June 2009 using time. I disagree, and this has been discussed many times before. Do you have any concrete use cases or examples of how marking these up using time would be necessary? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
[whatwg] listing element
Seems to be a listing element in 11.2.2 Display types http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-css-user-agent-style-sheet-and-presentational-hints What's that? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] input type=url allow URLs without http:// prefix
On Sun, 12 Jul 2009 15:48:51 +0100, Kornel Lesinski kor...@geekhood.net wrote: On Sun, 12 Jul 2009 09:46:19 +0100, Bruce Lawson bru...@opera.com wrote: I'd like to suggest that input type=url allows the http:// prefix to be optional on input and, if ommitted, be assumed when parsing. The spec explicitly allows that actual value seen and edited by the user in the interface is different from DOM value of the input, so browsers are free to prepend http:// automatically (and IMHO should – DSK-253195). Excellent. And, while I don't doubt you at all, I'm abashed that I missed that nuance, especially as it'#s explicitly allowed? Where would I find that in the spec? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
[whatwg] input type=url allow URLs without http:// prefix
Hi Cabal The eleventy squillion WordPress sites out there that allow comments ask for your web page address as well as name and email. The method of entering a URL does not require the http:// prefix; just beginning the URL with www is accepted. As it's very common for people to drop the http:// prefix on advertising, business cards etc (and who amongst us reads out the prefix when reading a URL on the phone?) I'd like to suggest that input type=url allows the http:// prefix to be optional on input and, if ommitted, be assumed when parsing. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] input type=url allow URLs without http:// prefix
On Sun, 12 Jul 2009 10:15:50 +0100, Geoffrey Sneddon foolist...@googlemail.com wrote: How do we tell apart foo.html (a relative URL) and example.com (a host name)? good point. It never occurred to me that relative URLs would be entered. What's the use case? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] ambiguity in header definition
On Mon, 29 Jun 2009 14:54:48 +0100, Thomas Broyer t.bro...@gmail.com wrote: perhaps the language should be tightened? ie A header element typically contains the section's heading (an h1–h6 element or an hgroup element), but this is not mandatory and may contain content such as navigation, a search form blah blah The fact that it is phrased as typically contains ... but can also contain makes it clear (for me) that it might contain a section's heading but this is not enforced (otherwise, it wouldn't say typically) my beef is with the words can also contain, which suggest that it can contain other stuff in addition to h1..h6, hgroup (which it can) but it's ambiguous as to whether it must contain h1..h6, hgroup as a minimum. (We're getting asked this a lot in html5doctor) -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
[whatwg] ambiguity in header definition
spec says A header element typically contains the section's heading (an h1–h6 element or an hgroup element), but can also contain other content I read this as other meaning different - e.g., header doesn't need to contain an h1–h6 element or an hgroup element. Others I know read other here as meaning additional , eg that it should have an h1–h6 element or an hgroup element but *may* have nav etc. I believe that the phrase Contexts in which this element may be used: Where flow content is expected means I win the beer and the curry, but perhaps the language should be tightened? ie A header element typically contains the section's heading (an h1–h6 element or an hgroup element), but this is not mandatory and may contain content such as navigation, a search form blah blah -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
[whatwg] editorial ambiguity in definition of nav?
Spec says The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-nav-element Primary navigation blocks is ambiguous, imo. A page may have two nav blocks; the first is site-wide naviagtion (primary navigation) and within-page links, eg a table of contents which many would term secondary nav. Because of the use of the phrase primary navigation block in the spec, a developer may think that her secondary nav should not use a nav element. Suggest rewording along the lines of only sections that consist of blocks whose primary purpose is navigation around the page or within the site are appropriate for the nav element, so - for example - lists of links to sponsors/ advertisers would not be marked up as nav elements. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] request for clarification: aside, figure
On Tue, 09 Jun 2009 01:57:15 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 10 May 2009, Bruce Lawson wrote: I don't think the spec is clear enough defining these two elements from an author's perspective. .. What is the difference between a figure that has no caption and an aside? Both seem to be connected in some way with the main content around it, but can be considered separate/ may be moved. .. So If I have a magazine-style pullquote, is that a figure or an aside (or neither)? I have attempted to address this, but actually it turns out HTML5 already has examples of how to do pull quotes in the aside section. I didn't express myself clearly enough. This isn't a problem per se - it's the symptom of a problem. I note that there is an example of how to do pullquotes, but I can't deduce the logic that makes it obvious why one should use an aside rather than figure; the definition of each seems to allow either to be used thus. For example, in the middle of a fictional interview about markup, I might want to pull out a quote and citation: Do I write aside blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote citeIan Hickson/cite /aside Or figure blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote legendIan Hickson/legend /figure The former shows correct usage of aside vs figure, though the cite element usage is incorrect; the name should not be marked up. Again, I see no spec-derived reason why it should be aside rather than figure, other than it happens to be given an example of one rather than the other. I have no preference, just seek to eliminate ambiguity. (Given that marking up a name as a citation is common practice, and validator cannot distinguish between a name and a title of a work, should we widen the definition of cite to match the English language defintion 1. to quote or refer to (a passage, book, or author) ? A different discussion, apologies)
Re: [whatwg] A new attribute for video and low-power devices
On Tue, 19 May 2009 07:03:14 +0100, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On 18/5/09 22:28, Benjamin M. Schwartz wrote: Then I will attempt to convince you. Suppose the additional attribute is a boolean called decorative, defaulting to false if not present. Note that /if/ ARIA roles are ultimately incorporated in text/html, that would more or less duplicate role=presentation. http://www.w3.org/TR/wai-aria/#presentation Good spot, Benjamin. Hixie said in an interview I did with him ..The plan is to make sure ARIA and HTML5 work well together. Right now I’m waiting for ARIA to be complete (there are a number of last call comments that they haven’t yet replied to), and for the ARIA implementation rules to be clearer (it’s not yet obvious as I understand it what should happen when ARIA says a checkbox is a radio button, for instance). Once that is cleared up, I expect HTML 5 will give a list of conformance criteria saying where ARIA attributes can be used and saying how they should be implemented in browsers. http://www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/ So perhaps this is a leverageable synergy?
[whatwg] request for clarification: aside, figure
I don't think the spec is clear enough defining these two elements from an author's perspective. The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. The figure element represents some flow content, optionally with a caption, which can be moved away from the main flow of the document without affecting the document's meaning. What is the difference between a figure that has no caption and an aside? Both seem to be connected in some way with the main content around it, but can be considered separate/ may be moved. Common-sense suggests that a figure is usually an illustration/ diagram/ picture, but doesn't have to be (the spec gives an example of the poem Jabberwocky marked up as a figure). So If I have a magazine-style pullquote, is that a figure or an aside (or neither)? For example, in the middle of a fictional interview about markup, I might want to pull out a quote and citation: Do I write aside blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote citeIan Hickson/cite /aside Or figure blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote legendIan Hickson/cite /aside -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] request for clarification: aside, figure
On Sun, 10 May 2009 08:58:47 +0100, Bruce Lawson bru...@opera.com wrote: Typo in last email: I meant For example, in the middle of a fictional interview about markup, I might want to pull out a quote and citation: Do I write aside blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote citeIan Hickson/cite /aside Or figure blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote legendIan Hickson/legend /figure
Re: [whatwg] Spec should require UAs to have control to mute/ pause audio/ video
On Fri, 08 May 2009 02:10:20 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, May 7, 2009 at 10:17 AM, Bruce Lawson bru...@opera.com wrote: Should autoplay be removed as an attribute of audio and video, precisely to remove such annoyance from people who rely on aural browsing? While there are video sites such as youTube that do play videos automatically, others such as vimeo don't. Is there an archive that lists the use-cases for autoplay and contrasts it with the annoyance and accessibility issues?. I'm convinced by Simon Pieters that removing the autoplay attribute wouldn't solve matters as people would just use script, and a browser option that disables autoplay across the board is better. But that adds weight to my greater argument for a mandatory control on autoplayed media allowing user to mute sound. Relying in the operating system's volume control is not the option as that mutes the offending sound *and* screenreader output, so the rest of the content is inaudible. I don't see why this should be a browser requirement. UAs are *allowed* to provide such a facility to their users, so if your UA doesn't, complain until they do! Perfect solution for those who live in Utopia. But as many users neither choose their browsers, or are unable to change them, it's better to require it of the browser. bruce -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
[whatwg] Spec should require UAs to have control to mute/ pause audio/ video
This may already be in the spec, but I couldn't find it. I think the spec should explicity require UAs to provide a mehanism to mute audio and to pause video, even if the controls attribute is not set. This will be of great benefit to screenreader users, as well as to people who work in shared environments and who may not be expecting noise. (There is a precedent for worrying about mere annoyance: User agents should not provide a public API to cause videos to be shown full-screen. A script, combined with a carefully crafted video file, could trick the user into thinking a system-modal dialog had been shown, and prompt the user for a password. There is also the danger of mere annoyance, with pages launching full-screen videos when links are clicked or pages navigated.) Should autoplay be removed as an attribute of audio and video, precisely to remove such annoyance from people who rely on aural browsing? While there are video sites such as youTube that do play videos automatically, others such as vimeo don't. Is there an archive that lists the use-cases for autoplay and contrasts it with the annoyance and accessibility issues?. (see http://www.brucelawson.co.uk/2009/accessibility-of-html5-video-and-audio-elements/) -- Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] Question on (new) header and hgroup
On Thu, 07 May 2009 16:34:21 +0100, James Graham jgra...@opera.com wrote: So, in the first example A new era of loveliness is a real section heading and the navigation becomes a subsection of that section. In the second example the hgroup element tells us that the h1 and h2 elements form a heading-subheading pair and that the navigation is a subsection of the section headed by this heading/subheading pair. Is that any clearer? much, thanks. Does your sectioning outliner utility now take these changes into account, by the way? -- Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] converting word (was code attributes
On Fri, 01 May 2009 12:22:32 +0100, Adrian Sutton adrian.sut...@ephox.com wrote: The biggest challenge in this is actually removing the huge amount of inline formatting and proprietary tags/attributes that Microsoft Word adds. In the latest versions it's also a challenge to put lists back together as actual HTML lists since Word has started exporting them as paragraphs with a bullet from the symbol font and lots of nbsps. Off topic, I know - but couldn't a VBA macro hook into word and actually make an export as semantic html option that exported the heading levels as h1..h6, honoured bold, italics, links, bullets and numbers as ul and ol, and just ignored all colours, font changes etc. So there is nothing to clean up? bruce
Re: [whatwg] time
On Thu, 12 Mar 2009 17:05:38 +0530, Lachlan Hunt lachlan.h...@lachy.id.au wrote: I think the design principles that are applicable here include Solve Real Problems [2], Real problems to be solved: 1) microformats have accessibility problems with abbr; time element solves that - but if the only valid use is to mark up future events (as Henri suggests), then pages become invalid as they age. (Much like me, actually) 2) microformats are already used in the wild to mark up past events. sometimes ancient and sometimes without DDMM precision. People who wish to do that won't be able to use time, so it perpetuates the accessibility problems it wishes to solve and fragments the way dates are marked up on the Web; some will use time, some will use microformats Therefore, extending the range of dates that can be marked up with time promotes accessibility, and caters for an existing requirement to mark up dates. Why do people want to mark up dates? I don't know. I don't know what people will use datagrid for, but I'm sure they will - and I know there are no clients out there that can use datagrid but that's not a reason to consign it to the bin in a kind of chicken-and-egg reductionism. I know that we don't want to bloat the language with new elements for every conceivable wish, but we're not talking about a new element, we're talking about further extending the usefulness of one. What advantage is there for authors and consumers by *not* extending the range of dates that can be described with time ? b
[whatwg] Historic dates in HTML5
Here are some (randomly selected) examples of microformats that are already being used to mark up historical dates in wikipedia, of the kind that would be illegal for 2 reasons; firstly, because they are not in the future, and also because they aren't precise (eg full -MM-DD format) or are ancient. http://en.wikipedia.org/wiki/Public_Worship_Regulation_Act_1874 http://en.wikipedia.org/wiki/Septennial_Act_1715 http://en.wikipedia.org/wiki/George_Washington_Carver http://en.wikipedia.org/wiki/John_Everett_Millais (birth date in hCard) 1066 has one hCalendar, with: SPAN class=summary dtstart1066/SPAN : http://en.wikipedia.org/wiki/1066 In my opinion, in order for the time element to succeed, it must be capable of doing the same job as microformats, or - as Henri says - the time element will not succed. Andy Mabbett has already listed use cases http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-February/018639.html Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (find me all the pages about events in 1923 — recent developments in Yahoo's YQL searching API (which now supports searching for microformats): http://developer.yahoo.net/blog/archives/2009/01/yql_with_microformats.html have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a SIMILE http://simile.mit.edu/timeline/ or similar time-line. They can be translated into other languages more effectively than raw prose; they can be disambiguated (does “5/6/09 mean “5th June 2009? or “6th May 2009?); and they can be presented in the user's preferred format. I suggest that the short list of apps that consume microformatted historical data should not be used to indicate that it's not a worthwhile use case. After all, I know of no user agents that can use time, section, footer, datagrid etc but we mostly expect there to be soon. -- Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
[whatwg] Historic dates in HTML5
Henri Sivonen said (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018687.html) The time element is meant as a replacement for the microformat abbr design pattern in hCalendar (if the microformat community embraces time; if not, time in pretty much pointless in HTML5). The expected use cases of hCalendar are mainly transferring *future* event entries from a Web page into an application like iCal. If there's one thing that getting involved in specs of markup languages has taught me, it's that expected use cases don't matter. People always do other things. And if there is a limit on a use case, it should be in the spec. There is nothing I can see in the editors draft that limits the use of time. (I use it on my website to markup publication dates of blog entries and comments; why on earth wouldn't I?) What it does limit is the format: no fuzzy dates like July 1897 for my great grandmother's birthday (no-one remembers the exact day) or the precise date of Charlemagne death 28 January 814 Henri is right: codetime/code is pretty much pointless in HTML5 if it's not embraced by the microformats community, but why would they embrace it? It prevents them doing a lot of what they do - like fuzzy or ancient dates - so what do they gain by adopting it? -- Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
