Re: [whatwg] Add 'type' attribute to mark
On Oct 31, 2008, at 7:57 PM, Ian Hickson wrote: That's what the class attribute is for. What's the difference then between mark and span then? I mean, does the mark element provide anything that span with an appropriate class wouldn't? A default style when there's no CSS support, support in accessibility tools, the ability for search engines to understand what's going on, easier round-tripping between editors, simpler rules in CSS and other selector-like environments, etc. The usual benefits of semantics. Are we talking about assigning particular meanings to certain class names? Or are we saying this is for semantic purposes, but do whatever you want with it, because nobody will see it except UAs that are applying CSS rules and users who view the HTML source code? If the former, it's a terrible idea because developers have been working with the assumption that there are no reserved keywords so there are bound to be conflicts. If the latter... it doesn't really mean anything, does it? By the way, I gave a ridiculous example earlier of why defining class=footnote to have semantic meaning would be bad; I got really bored and fleshed out that example: http://phroggy.com/musicalfeet/ -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Add 'type' attribute to mark
The spec already describes how to do footnotes: http://www.whatwg.org/specs/web-apps/current-work/#footnotes Yes, but this is a theoretical explanation that does not provide a consistent, practical solution. As the mark element has different usages defined on it already why not include a type attribute (or similar) that defines what it is used for. One of these types would then be footnote, others could be (relating to what is already in the spec) term, highlight etc. (I am sure others would be much better at thinking up names than I am). That's what the class attribute is for. Like I said before, I think class (and id) should be reserved for styling and not be content/semantic related at all. It is strange how we all advocate separation of the two but allow these attributes to encompass descriptive values for both. Bert
Re: [whatwg] Proposing URI Templates for WebForms 2.0
Mark Nottingham wrote: ... Try what I did with hinclude http://www.mnot.net/javascript/hinclude/; write a javascript library to handle a declarative syntax, and have it gracefully degrade once the browsers handle it natively. If the markup is declarative, it doesn't matter if it's in HTML5 or not, you still can cater to unintended uses. ... Speaking of which: that one (hinclude) is totally useful; and it would also help with one of the cases Google's recent dictionary-based compression proposal is for. I'd totally be in favor to have something like this in HTML5 (and no, others have asked for it as well). BR, Julian
Re: [whatwg] Add 'type' attribute to mark
On Sat, 1 Nov 2008, Andy Lyttle wrote: On Oct 31, 2008, at 7:57 PM, Ian Hickson wrote: That's what the class attribute is for. What's the difference then between mark and span then? I mean, does the mark element provide anything that span with an appropriate class wouldn't? A default style when there's no CSS support, support in accessibility tools, the ability for search engines to understand what's going on, easier round-tripping between editors, simpler rules in CSS and other selector-like environments, etc. The usual benefits of semantics. Are we talking about assigning particular meanings to certain class names? All class names have meaning. That's what the class attribute is for -- it's a way for authors to extend the language to cover semantics the language doesn't have, using terms they have defined for their page, site, or organisation. Or are we saying this is for semantic purposes, but do whatever you want with it, because nobody will see it except UAs that are applying CSS rules and users who view the HTML source code? If by this you mean the class attribute, then neither; it's an extension mechanism, authors should use it for the purpose of annotating their semantics so that they can use those annotated semantics from other contexts (such as tools, scripts, style sheets, etc). On Sat, 1 Nov 2008, Pentasis wrote: The spec already describes how to do footnotes: http://www.whatwg.org/specs/web-apps/current-work/#footnotes Yes, but this is a theoretical explanation that does not provide a consistent, practical solution. I don't understand why these solutions aren't consistent or practical. As the mark element has different usages defined on it already why not include a type attribute (or similar) that defines what it is used for. One of these types would then be footnote, others could be (relating to what is already in the spec) term, highlight etc. (I am sure others would be much better at thinking up names than I am). That's what the class attribute is for. Like I said before, I think class (and id) should be reserved for styling and not be content/semantic related at all. I'm afraid that's not what class and id are for, they are entirely intended as a way for authors to annotate their semantics in more detail. It is strange how we all advocate separation of the two but allow these attributes to encompass descriptive values for both. You should never use class (or id) for specifically stylistic reasons. You should use class to annotate the semantics, and then separately use the style sheets to hook onto your annotated semantics to get the style you want in more fine grained detail than the elements allow. This is why values like class=big or class=green are bad, but values like class=footnote or class=user-search-terms are fine. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WF2 terminology: tokens vs. productions
On Wed, 21 Nov 2007, Henri Sivonen wrote: Quoting the spec: An e-mail address, following the format of the addr-spec token defined in RFC 2822 section 3.4.1 [RFC2822], but excluding the CFWS subtoken everywhere, and excluding the FWS subtoken everywhere except in the quoted-string subtoken. The text should probably talk about productions instead of tokens. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Add 'type' attribute to mark
Yes, but this is a theoretical explanation that does not provide a consistent, practical solution. I don't understand why these solutions aren't consistent or practical. First of all, the spec admits it itself: HTML does not have a dedicated mechanism for marking up footnotes. Here are the recommended alternatives. Alternatives are not real mechanisms. It gives us the option of using the title attribute (which has no mechanism of expansion and we cannot group them). Then it gives us the a element solution, which is how it is already done in most cases but leaves much to be desired (there are plenty of articles about it on the web). And last it tells us we can use the aside element. But in this example there is no *direct* relation to the actual word/phrase we put in the aside. It also gives us -again- no direct mechanism of expansion and no way of grouping footnotes/sidenotes. Now, I am perfectly happy for this spec not to provide a footnote construct, but in that case I would strongly suggest removing these alternatives and simply say it should be resolved using scripting (which has much more flexibility) or not say anything at all about it. Like I said before, I think class (and id) should be reserved for styling and not be content/semantic related at all. I'm afraid that's not what class and id are for, they are entirely intended as a way for authors to annotate their semantics in more detail. You should never use class (or id) for specifically stylistic reasons. You should use class to annotate the semantics, and then separately use the style sheets to hook onto your annotated semantics to get the style you want in more fine grained detail than the elements allow. This is why values like class=big or class=green are bad, but values like class=footnote or class=user-search-terms are fine. I will agree to the fact that this is the general consensus. And I have been doing it like that for a long time as well. But I will leave it at that, this is an entirely different discussion which has nothing to do with footnotes and I apologize for bringing it up. Bert
Re: [whatwg] Add 'type' attribute to mark
On Sat, Nov 1, 2008 at 11:13 AM, Pentasis [EMAIL PROTECTED] wrote: Yes, but this is a theoretical explanation that does not provide a consistent, practical solution. I don't understand why these solutions aren't consistent or practical. First of all, the spec admits it itself: HTML does not have a dedicated mechanism for marking up footnotes. Here are the recommended alternatives. Alternatives are not real mechanisms. It gives us the option of using the title attribute (which has no mechanism of expansion and we cannot group them). Then it gives us the a element solution, which is how it is already done in most cases but leaves much to be desired (there are plenty of articles about it on the web). And last it tells us we can use the aside element. But in this example there is no *direct* relation to the actual word/phrase we put in the aside. It also gives us -again- no direct mechanism of expansion and no way of grouping footnotes/sidenotes. Now, I am perfectly happy for this spec not to provide a footnote construct, but in that case I would strongly suggest removing these alternatives and simply say it should be resolved using scripting (which has much more flexibility) or not say anything at all about it. Grouping and such is a stylistic concern, though - as long as the document expresses a footnote semantic, that's all it has to do. For the rest, we have a CSS Module that will cover that area, the Generated and Replaced Content module [1]. By an astonishing coincidence, the editor of this module is no less than Ian himself. [1]: http://www.w3.org/TR/css3-content/ ~TJ
Re: [whatwg] Add 'type' attribute to mark
Grouping and such is a stylistic concern, though - as long as the document expresses a footnote semantic, that's all it has to do. For the rest, we have a CSS Module that will cover that area, the Generated and Replaced Content module [1]. By an astonishing coincidence, the editor of this module is no less than Ian himself. [1]: http://www.w3.org/TR/css3-content/ ~TJ In that case why don't they drop the abbr, dfn, cite, mark etc. elements? They can be styled through CSS as well and be semantically determined by using a class-name just as sugested for footnotes. Bert
[whatwg] Cascading Attribute Sheets
In the add type to mark element discussion which I started, a side argument about ids and classes was brought up. I conveyed my opinion that I think classes should only be used as style handles and not to convey extra semantic meaning. The HTML4 spec states: The class attribute has several roles in HTML: * As a style sheet selector (when an author wishes to assign style information to a set of elements). * For general purpose processing by user agents. The first role is clear, it is used for styles (not semantics) the second is a bit more muddy I think, but the important part there is: processing BY user agents. User agents have no interest in semantics, so I fail to see here also why classes may be used to define semantic roles. The fact that a class should be named footnote for example is only so you will not get in trouble (unlike when you use a name like red or left). But this only tells me (the author) that this element should be styled like a footnote and for the user agent that it should render it like a footnote. It should not tell me (or anything else) that it IS a footnote. This would lead inevitably to inflexibility. Let me however put forth a -maybe silly- idea I have had for a long time. In seperating content from style it would seem logical to me that the next step would be to place most attributes (except id and a new role-attribute) also in an external file. Assignment of attributes and purpose can then also be done externally from the html-file leaving it only to contain pure content. (this would benefit SEO, machine readability, accessibility and maintainability). The obvious benefits would be that one can maintain things externally like: links, images, accesskeys, list-numbering, hiding, etc. and if we would assign a common attribute to all elements called edit we could set that externally too (like draft, deleted, approved, date, etc.). but the biggest benefit (I think) is that we can set classnames externally. this way we do not have to touch the html-file to change styles, but simply change the properties in the external attribute sheet. The new role attribute would be completely semantic and classes are no longer indide the html so their naming can be more style-related. And changing a style would no longer mean changing the stylesheet, but changing the attributesheet. It would make CSS a little bit more modular (and flexible). Well, let me have it ;-) Bert
Re: [whatwg] Add 'type' attribute to mark
First of all, I'd like to avoid any missunderstandings: I have nothing
against the mark element itself; although I'm afraid my previous
e-mails may lead to think otherwise. It could be a really good
addition to HTML but, IMHO, it isn't yet, and I'm trying to show why I
think so.
On Sat, Nov 1, 2008 at 2:57 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 1 Nov 2008, Eduard Pascual wrote:
[...]
What's the difference then between mark and span then? I mean, does
the mark element provide anything that span with an appropriate
class wouldn't?
A default style when there's no CSS support, support in accessibility
tools, the ability for search engines to understand what's going on,
easier round-tripping between editors, simpler rules in CSS and other
selector-like environments, etc. The usual benefits of semantics.
Let's take that point by point:
- A default style when there's no CSS support: that's entirely
presentational; and although I may accept it as a side-bonus, I don't
feel presentational arguments are a good base for including/excluding
a new element.
- Support in accessibility tools: that's plain daydreaming: what kind
of support can an AT provide without any hint on whether the mark'ed
text is a search term, or the line of a code snippet that caused a
crash, or the total price of the orders in a shopping cart, or
whatever other usage authors may come up with?
- The ability for search engines to understand what's going on??
Comming from someone else, I'd think they are simply wrong, but
comming from Ian I really hope you were joking: besides a SE would be
as clueless on that aspect as an AT; this would extremelly easily
abused by black hat SEO, to the point of making the element
completely meaningless for SEs: just a mark { display: none; } rule
and a site becomes able to freely spam highlighted keywords across
the entire page. And, although many SEs are capable of checking CSS
sheets, it's almost trivial to achieve the same from JavaScript, and
even to obfuscate the script if any SE managed to figure the trick
out.
- Simpler rules in CSS and other selector-like environments: I simply
can't believe that this came from an editor of the CSS3 Selectors
module. How much simples is mark than .match, .crash_line,
.total, and so on? The only difference is a single dot; plus the
fact that classes give much more flexibility that directly styling (or
selecting on any other similar environment) could ever allow. And
finally, it's worth to mention that, as soon as a page needs to use
mark for two or more different purposes, there is no other way to
differentiate them in selectors than classes (and no way at all for
ATs or SEs to differentiate then, BTW).
- The usual benefits of semantics. Honestly, that's a really good
purpose; it's only that it's not achieved. If you look again at the
counter-arguments above, you should be able to notice that they are
nothing else than the usual drawbacks of lack of semantics. Because,
simply put, the semantics defined for mark are so vague that, in
practical terms, they are the same as no semantics at all. Pentasis's
initial proposal would be a simple and efficient solution to this
issue: with some sort of type/role/whatever attribute (based on a
well-defined list of allowable values), an AT could tell the user why
some text is marked, a SE could figure out what's really going on, and
a designer could rely on that attribute upon selection instead of
defining classes with an entirely presentational purpose.
Well, that's my opinion, just wanted to share it.
Re: [whatwg] Cascading Attribute Sheets
On Sat, Nov 1, 2008 at 6:11 PM, Pentasis wrote: In the add type to mark element discussion which I started, a side argument about ids and classes was brought up. I conveyed my opinion that I think classes should only be used as style handles and not to convey extra semantic meaning. The HTML4 spec states: The class attribute has several roles in HTML: * As a style sheet selector (when an author wishes to assign style information to a set of elements). * For general purpose processing by user agents. The first role is clear, it is used for styles (not semantics) Ian answered to this. You'll similarly or identically style elements with similar or identical meaning; in other words, you'll attach style to semantics, so your class names are likely to markup your document with additional semantics. the second is a bit more muddy I think, but the important part there is: processing BY user agents. User agents have no interest in semantics, so I fail to see here also why classes may be used to define semantic roles. Microformats. The fact that a class should be named footnote for example is only so you will not get in trouble (unlike when you use a name like red or left). But this only tells me (the author) that this element should be styled like a footnote and for the user agent that it should render it like a footnote. It should not tell me (or anything else) that it IS a footnote. This would lead inevitably to inflexibility. Why not enclose your footnotes in aside elements? Moreover, a note is not necessarily presented as a footnote (i.e. moved to the end of the page), it can be shown in the margin (as in the WHATWG version of the HTML5 spec) or in popup panels when you click on a word or footnote reference (similarly to definitions in the old HTMLHelp on Windows). -- Thomas Broyer
[whatwg] HTML5 and URI Templates
(In the interests of avoiding cross-posting, I have only sent this e-mail
to the whatwg list. The original e-mails were also crossposted to the IETF
URI list and the rest-discuss list.)
This might be a good time to bring the FAQ to people's attention -- it
covers what we ask people to go through when proposing new features:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F
I encourage people to follow this process.
On Sat, 15 Dec 2007, James M Snell wrote:
The gist of the idea (which I believe may have been brought up before
but I'm not certain) is to allow the use of a URI Template in place of
the form element action attribute, and to use form elements to provide
the replacement values, e.g.
form template=http://example.org{-prefix|/|foo}?bar={bar}
method=POST
Foo: input name=foo type=input
Bar: input name=bar type=input
/form
Why isn't the current form submission mechanism, with a redirect on the
server-side, not acceptable?
On Fri, 21 Dec 2007, James M Snell wrote:
FYI... I've put together a quick prototype example [1] of a html form
using a URI Template [2]. The processing of the template is performed
in the onsubmit event of the form.
- James
[1] http://www.snellspace.com/wp/?p=832
[2] http://www.snellspace.com/wp/?p=831
This is great -- why is it not enough?
I have to admit to being a little concerned over the complexity of the URI
template language as currently proposed.
On Fri, 31 Oct 2008, Jerome Louvel wrote:
It would just be easier to take advantage of them directly from HTML.
Right now, a Web form can already build a URI by adding query parameters
to the action URI of a GET form, why not go a bit further?
Because it adds significant complexity to the browser platform, without
really adding new functionality.
The benefit would be having more control over the construction of the
URI rather than just the query parameters. I could have a form with two
simple fields a and b and specify
http://test.org/customers/{a}/reports/{b}; as the action URI.
I don't understand why this is such a big deal. Such, the URIs are nicer,
but, big deal. Just do a redirect if it matters that much.
On Sat, 1 Nov 2008, Mark Nottingham wrote:
Doing it in script precludes unintended reuse, e.g., for accessibility,
search engines, and so forth [...]
Why would scripts preclude accessibility? And are you really expecting
search engines to fill in forms that would use templates? (Some search
engines fill in forms, but it's usually for searches, where the content
would most properly be in the query component.)
On Fri, 31 Oct 2008, Mike Schinkel wrote:
What classifies as a compelling use-case in your mind?
Something that can't be done without the feature. Something that allows
authors to write applications that make users say wow!, which they can't
do today.
On Sat, 1 Nov 2008, Mark Nottingham wrote:
The benefits you're talking about seem to be all related to having more
flexibility in specifying URIs from forms. This is good and I agree that
in a perfect world, more flexibility would have been designed in from
the start. However, to put them into the mix while the machine is
running is a bit more complex; there needs to be something more
compelling (there's that word again) to drive adoption.
Agreed.
On Sat, 1 Nov 2008, Mike Schinkel wrote:
Please PLEASE don't make us wait until 2032 or so for this! ;-)
You can do it now with redirects or scripts. It's not clear to me that
this is a feature that is important enough to ever be in the browser.
On Sat, 1 Nov 2008, Mark Nottingham wrote:
Because you're not introducing your idea to a new proposal that will
succeed or fail on its own merits; you're trying to get it into one of
the most widely-used formats in the world. As such, the barrier to entry
is higher; it has to be, or every idea that seems to be good would get
in, and HTML5 would be even more incomprehensible than it is now.
Indeed,
I'm not the person to ask that, but frankly if you want the
functionality, go ahead and write the software, publish the site,
release the browser plug-in; the standards will follow if the minds do.
That's how many parts of HTML5 have made it in.
On Sat, 1 Nov 2008, Mike Schinkel wrote:
Adding URI Templates to forms fills a large hole in the forms
architecture; This is very much a case of empowering serendipity as the
current form architecture current cannotly service the full range of
URLs that can be used. I'm asking for (most of) that gap to be filled.
There are many many gaps, why is this an important one to fill?
On Sat, 1 Nov 2008, Mike Schinkel wrote:
I can understand, appreciate and respect that. FYI I lost patience with
the standard process a while back because it seemed that no matter my
input I was always told no. Since I only found frustration, I gave
up.
I'm participating
Re: [whatwg] [WF2] form.submit() should not throw if form is invalid
On Thu, 10 Jan 2008, Hallvord R M Steen wrote: I think some changes are required to make WF2 more web-compatible. In particular, we need a clean way JS can override WF2's validation. Cancelling an invalid event just prevents the UA's built-in message - we need something that makes submission happen anyway. The best candidate is the submit() method - if we drop the requirement that it throws an error if the form is invalid. As specified, WF2 breaks *a lot* of pages which use custom JS libraries for validation, trigger WF2 rules by coincidence and expect to be able to submit forms with form.submit(). Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
