Re: [whatwg] [HTML5] Named start values for lists?
dolphinling wrote: HTML5 brings back the |start| attribute on ordered lists. This allows a list to semantically start with a number other than one. It seems like the major use case for this is to split lists up, so that a single list is marked by multiple ols. Would it therefore make sense to allow named start values, so that the author doesn't have to go through and re-number everything when a new item is added at the top? And if so, should they be considered semantically one list? And if so, would it make sense for it to also apply to unordered lists, so that they can be split up, too? Or would all that be an abuse, and something that's one list should use only one ?l ? I've thought a bit more, and *assuming semantically linked, automatically numbered split lists should be allowed* (which so far only one other person has even touched on!), I think the best solution would be something like the following: pChores for today:/p ol listname=chores liClean living room/li liClean bathroom/li /ol pWhen cleaning bathroom, make sure to get all the grout between the shower tiles. Also, the sink needs to be scrubbed, too./p ol listname=chores liSweep kitchen/li liWash dishes/li /ol Numbering would start at 1, and continue in source order (superseded, of course, by any start= or value= attributes). This gives the author the power to number however they want, while being much less complex spec- and implementation-wise. A few cases where a list is not only split, but the sections are rearranged on the page, require the author to fall back on start=, but since it doesn't actually remove any functionality, I think that's an acceptable tradeoff. As for how this would interact with CSS Counters... It appears counters in CSS 3 are insufficient even to handle the already-in-spec start= and value= attributes. That should probably be taken up with the CSS WG. -- dolphinling http://dolphinling.net/
Re: [whatwg] image captions
Le 28 juin 2006 à 21:17, Lachlan Hunt a écrit : Michel Fortin wrote: figure captionFigure 1: Some image/caption img src=... /figure [...] The only problem is that it isn't very backwards compatible. Firefox doesn't include caption in the DOM outside of a table. Moving the caption after the image in the source and setting display: block; on the image gives reasonable results in Firefox and Opera because the img is a child of figure, but not in IE because figure and img are treated as siblings. I have exposed this problem previously (look back at this thread in April). In fact, my first thought was that this was a show-stopper for that particular syntax and that a substitue ought to be found. Then I realised that, contrary to my first belief, others elements in the current draft -- namely section, nav, header, footer, aside, and maybe others -- aren't backward compatible either because they can't contain even a paragraph, at least in Safari and Firefox. Will this prevent section and others from being adopted? I doubt it. Should this prevent a figure element from being adopted? I don't think so. Michel Fortin [EMAIL PROTECTED] http://www.michelf.com/
Re: [whatwg] [HTML5] Named start values for lists?
dolphinling wrote: As for how this would interact with CSS Counters... It appears counters in CSS 3 are insufficient even to handle the already-in-spec start= and value= attributes. That should probably be taken up with the CSS WG. I've mailed www-style (not with any ideas, just bringing it up). The thread should be named [CSS 3 counters] Dealing with ol start= and li value= ? However, my messages have a history of not going through there ( :o ), so if it's not there in a day or so and no one else has started a thread, perhaps someone can forward it for me? Subject: [CSS 3 counters] Dealing with ol start= and li value= ? The WHAT WG's WA1 draft brings back the start attribute on ordered lists and introduces a value attribute on individual list items, and semantic grouping of lists (saying two ol/ols are in fact one list) is being discussed. Unless I missed something in my (admittedly quick) reading, the Counters section in both CSS 2.1 and CSS 3 seems insufficient to deal with this. I don't actually have any thoughts on how to solve it, but just wanted to make sure it didn't get lost in the void. -- dolphinling http://dolphinling.net/ -- dolphinling http://dolphinling.net/
[whatwg] Spellchecking mark III
I believe this answers all outstanding e-mails on the subject, please let
me know if I missed one. I include a new proposal (still with a
spellcheck= attribute, based mostly on implementation feedback from the
Mozilla guys) at the end of the e-mail.
On Sun, 11 Jun 2006, Robert Gr�sdal wrote:
How about something like cascading behaviour sheets?
style type=text/cbs
#first-name {
inputmode: user startUpper;
spellcheck: enabled;
}
.cplusplus {
spellcheck: disabled;
autoindent: C++;
highlight: C++;
auto-evaluate: disabled;
}
.math {
spellcheck: math;
inputmode: math;
highlight: math;
auto-evaluate: enabled;
}
/style
I'd hate to have to specify all those attributes to every single input
field for sure.
Well, it wouldn't be stylistic per se, so I don't think it would belong in
the stylesheet. Even if you disable the styles, the spellcheck settings
still apply.
By the way - Hello everyone, this is my first post to the list.
Welcome!
On Sun, 11 Jun 2006, Matthew Raymond wrote:
If, however, we're really just talking about adding words to the UA
dictionary temporarily and for a specific site, couldn't we just do that
with meta using the same format as we do with keywords?
| meta name=vocabulary lang=en-us
| content=HTML5, WHATWG, WF2, WA1, WD1, CSS3-UI, TARDIS, ZPM, DHD
Are there actually situations where different controls would need
different vocabulary?!?
That's an interesting idea, but I'd shy away from doing this for now.
Let's start small and build up...
On Sun, 11 Jun 2006, Alexey Feldgendler wrote:
Maybe features like spellckeching, syntax highlighting and so on should
be controlled via CSS? That way, they can be fine-tuned to any degree of
precision without complicating the HTML schema. This will also reduce
verbosity of input elements because they would otherwise have the same
repeated attributes.
While I certainly sympathise with the concern of heavy input elements
(that's why I was against the spellcheck= attribute in the first place),
I don't think this is stylistic. Maybe we need another kind of macro
capability, such as XBL, for this problem.
Information like this input field should have autoindent is
presentational.
Yeah, but you'd have to say auto-indent this like C++, which isn't.
IMHO.
You should raise this in the www-style list, though, if you do think it
is appropriate.
On Sun, 11 Jun 2006, Lachlan Hunt wrote:
No, spell checking is a user agent feature that should be controlled by
the UA and the user. Authors should have no explicit control over it.
Besides, spell checking *is not* presentation, it is UA functionality
and so it does not belong in the presentation layer.
I agree that it isn't presentation, but I disagree that the author
shouldn't be able to suggest whether or not to enable it. More on this
below.
On Sun, 11 Jun 2006, Alexey Feldgendler wrote:
Besides, spell checking *is not* presentation, it is UA functionality
and so it does not belong in the presentation layer.
Visual elements = Presentation
Interactive elements = Behavior
I think these are similar relationships. BTW, isn't the cursor CSS
property about behavior?
The behaviour vs presentation debate is a rat hole. The key thing is
should this continue to work if you disable the author stylesheet and
should this continue to work if you stop using a screen.
It is clear, IMHO, that spellchecking being enabled or not is independent
of both whether the author's stylesheet is enabled or not and whether the
content is being displayed on a screen or not.
On Sun, 11 Jun 2006, Alexey Feldgendler wrote:
One can also say that authors should not have explicit control over
whether hyperlinks are underlined or not.
The difference is that underlining is presentation, spell checking is
not. The functionality of a link cannot be changed with CSS, likewise
spell checking shouldn't either.
Enabling or disabling spell checking doesn't change the functionality of
an input.
Sure it does. It changes whether or not the user's typos will be flagged
to the user or not. That seems like quite a big difference.
It can still be used to submit arbitrary text to the server.
By that argument. type=text vs type=password is a presentational aspect.
Or even more, type=text vs type=checkbox.
But misspelled words in an input with spellchecking enabled are
underlined with a wavy red line (and the underlining style could even be
changed by CSS), and that's presentation.
I agree that the line itself should be stylable in CSS (if at all), but I
disagree that the presence or absence of the line is a stylistic matter.
On Mon, 12 Jun 2006, Lachlan Hunt wrote:
While the core functionality of allowing the user to enter text isn't
changed, I'd consider spell checking to be part of the control's
functionality, and so disabling it
Re: [whatwg] Spellchecking mark III
At 23:56 + UTC, on 2006-06-29, Ian Hickson wrote: [...] On Mon, 12 Jun 2006, Alexey Feldgendler wrote: There's nothing really bad in allowing CSS to control behavior to some extent. CSS is the part of the document that can be disabled/replaced. If disabling the author styles changes the functionality of the page, then that's bad. Agreed. [...] On Thu, 15 Jun 2006, Sander Tekelenburg wrote: [...] Just like authors cannot know what font size is best for a user they cannot know whether a spellchecker is useful or a nuisance. But they can suggest what font-size might be most appropriate. I don't see how allowing authors to abuse one thing is an argument to give them more things to abuse :) I'm well aware that *everything* can be abused, but when something is useful enough then its potential for abuse is a downside you choose to live with. When something is not useful enough, the abusability argument should win. [...] On Fri, 23 Jun 2006, Sander Tekelenburg wrote: [AUTHOR REQUIREMENTS] Authors should set the document's language information, to enable user agents to accurately determine which dictionary to use when checking the spelling or grammar of user input. IMO this should should be a must. What about if the author doesn't know the language? Of the user input you mean? Good point. But then what if a page is in english but accepts input in any language? The author should still indicate the content's language, thereby triggering the wrong spellchecker for those who wish to input text in another language. In turn, the result may well be that authors set no lang attribute at all for the page. Surely a spec shouldn't push authors in that direction? A solution might be to make this a *must* and allow lang=*, so the author can state lang=en on the body, and lang=* on the input field. I still seriously doubt authors will use this as intended though... IMPLEMENTATION REQUIREMENTS All elements can have spellchecking enabled or disabled. UAs may allow the user to set this flag Why may? Why not must? [...] Because you can't require a particular UI. For example, the UA could be a kiosk-style system, where the user is not to have any ability to do anything but enter his text and hit submit. Good point. But if I'm not mistaken HTML 4.01 already says that some things do not apply to UAs that can't implement them. I think you should at least change this to a should, and add a note to the spec that explains that this means user-agents that can should, and only those that can't are excused. (To be clear: my argument is that the spec should do its best to avoid giving user-agents an excuse to not bother giving the user (easy) control.) [...] On Fri, 23 Jun 2006, Lachlan Hunt wrote: I don't particularly like giving the authors any control over spell checking. For the majority of cases, I think browsers should become smart enough to know whether or not to enable/disable spell checking without any explicit author input, based on various heuristics (as I've written about before [1]). In other words, for most cases, authors should not need to use this attribute. The request for this attribute came from a UA in the first place. This would seem to suggest they can't find a way to be smart enough, and would like author input. Not meaning to be disrespectful, but can't suggests it's simply too difficult technically, while it could just as well be that they prefer to take the easier way out, for instance because they can't afford spending the necessary resources on this. That can be a perfectly valid argument for an individual browser vendor, but it's hardly a solid basis for a HTML spec. Especially when the request comes from a single browser vendor and everybody else seems to see more problems than benefits. [...] Ok, so how can we ensure that spell checking is enable for GMail's To: line but enabled for its Subject line? Ordinarily, input type=email would handle no spell checking for email addresses, but given that Gmail uses a textarea that contains both people's names and email addresses, that may be one case where heuristics may not give optimal results. Indeed. So how should we do it, if not using an attribute to hint to the UA whether it should be enabled or not? I can't follow this. If a site uses 2 types of content within the same field and wants one of those types to be spellchecked, and the other not, how is a |spellcheck| attribute going to help? They'll need to split those 2 types of content into 2 different fields. (That aside, I don't see how users would have a problem with spellcheckers indicating spell errors on email addresses or names. Surely they're already used to ignoring that.) [...] since the entire discussion here was spawned by one such browser vendor saying we need a way for authors to control this!, I would suggest that browser vendors have determined that they need a way for authors to control this. :-)
