is).
Jukka K. Korpela (Yucca)
http://www.cs.tut.fi/~jkorpela/
in the sense that small takes effect even when told to ignore
font size settings on web pages. (That's what IE does, anyway.)
I would at any rate say that the current definition doesn't differ
very much from how it is now.
I'm afraid it does, and not in a positive direction.
Jukka K. Korpela
of i
would be that for the adequate use, you would happily, even eagerly
accept such secondary ways of expressing italics, whereas for the
inadequate use, that would be foolish.
Jukka K. Korpela (Yucca)
http://www.cs.tut.fi/~jkorpela/
Paul Arzul wrote:
we could use the Default style sheet for HTML 4:
http://www.w3.org/TR/CSS21/sample.html
That style sheet is purported to be both descriptive and prescriptive (read
the prelude carefully, and you'll see how messed-up it is). In reality, it
is neither. No browser implements
The current version disallows the size and maxlength attributes in input
elements when type=time, type=date, type=datetime,
type=datetime-local, type=number, type=range, or type=color is used.
I suppose the reason is that for other new input types, browsers are
expected to use advanced user
Bjartur Thorlacius wrote:
[quotation reorganized by me]
On 2/27/11, usuario soyh...@gmail.com wrote:
Tiis may seem somewhat silly, every front-end developer have ever
used a a wrapper div, shouldn't it be more semantic to have a
wrapper element?
If said wrappers don't have any semantics but
Mounir Lamouri wrote:
Note that input type='time' maxlength='5' size='5' should work as
expected given than maxlength and size would just be ignored by a UA
which knows about the 'time' type and would be used by a UA which
doesn't.
My point exactly.
Though, if you want to have a valid HTML
Markus Ernst wrote:
Searching for implementations of input type=color, I found that Opera
actually implemented the color picker quite similar to my suggestion.
It's a rather nice implementation, and your comments made me test it a bit
more, and it indeed makes use of a datalist element if
Markus Ernst wrote:
select
option label=Label1TextContent1/option
option label=Label2TextContent2/option
/select
- IE 8, Opera 11 and Chrome 9 display Label1 and Label2
- Firefox 3.6 displays TextContent1 and TextContent2
Firefox's behavour seems to be contradictory to the spec, which
Jonas Sicking wrote:
I'm having a little bit hard of a time figuring out what a good UI
would look like in the general case. I.e. what should the UI look like
for
input type=date id=date name=date
value=2011-04-01 list=datelist exclusive
datalist id=datelist
option value=2011-04-01 label=April
Christoph Päper wrote:
Diogo Resende:
I was thinking.. what about allowing big time spans, like: from
April 1st to June 30th? Giving that the date has - as date element
separators we could not use 1-MM1-DD1-2-MM2-DD2.
ISO 8601 specifies how to code time intervals (and durations) in
The p element (ever since it became an element) has always allowed inline
(text-level) content only, and no change is planned to this in HTML5. Under
these circumstances, what should we say to people to need to use paragraphs
that contain lists, for example?
A paragraph, in the old
Markus Ernst wrote:
Would it cause serious issues to add the Phrasing Content category to
these three elements [ol, ul, dl] thus allowing them inside the p element?
I'm afraid it would, and I think that's the reason why the content model
hasn't been extended in HTML5.
Consider
psome
James Graham wrote:
On 03/10/2011 09:20 AM, Jukka K. Korpela wrote:
My question is: Is this acceptable use of the SECTION element, even
in a flow that mostly consists of P elements, not wrapped inside
SECTION elements of their own?
If I understand you correctly, it is not the intended use
Christoph Päper wrote:
A new type is probably not necessary, because a new attribute that is
called something like ‘unit’ and is only valid in the ‘number’ and
‘range’ states could be enough.
input type=number id=fontsize value=12 unit=pt
I don't quite see the point (no pun intended). It
Boris Zbarsky wrote:
On 3/24/11 9:29 PM, Nicholas Zakas wrote:
[...]
Fixing the issue results in:
div
style scoped.foo { color: red; }/div
/div
The correct fix for this issue is to put this style in the head,
isn't it? Why would would you fix it by adding @scoped?
There is nothing
Boris Zbarsky wrote:
On 3/25/11 9:49 PM, Nils Dagsson Moskopp wrote:
More precisely, under what circumstances does
an author have control over the very start ofbody, but not over
head?
I can see how some sort of template setups might have that, where the
head is controlled by the overall
Boris Zbarsky wrote:
If you can only affect _some_ parts of the body you should in fact
be using style scoped, no?
No, because the parts might appear around the body so that you cannot use
any wrapper that contains them all. It would be awkward to use copies of the
same stylesheet in
Eduard Pascual wrote:
If you look closer at the scenario you describe (having control over
sparse parts of the body, but not the full document), we don't
really want to enable un-scoped stylesheets there: they could easily
interfere with (up to completely screwing up) the parts of the
document
Alexandre Morgaut wrote:
My biggest nightmare today is that recent browsers like Chrome, IE9,
FF4 generate a global variable from the id of each HTMLElement of the
document...
On a day like this, I was very suspicious about information like that, but
it turns out to be true and also applies
Lachlan Hunt wrote:
If details default Boolean setting of 'hidden' results in the
equivalent of CSS's {display:none;} (where the content is taken
completely out of the page flow, both visually and in the DOM tree)
then this would likely be a possible alternative to @longdesc
Yes, it should be
James Graham wrote:
On 04/07/2011 05:55 PM, Tab Atkins Jr. wrote:
On Thu, Apr 7, 2011 at 6:09 AM, Lachlan
Huntlachlan.h...@lachy.id.au wrote:
3. We'd like to get some feedback from web developers, and
agreement from other browser vendors, about exactly which glyphs
are most appropriate to
Lachlan Hunt wrote:
Regardless of whether or not we agree on a common glyph to use for
this, we should at least agree on the applicable CSS styles used to
achieve
the rendering, which is essential so that authors have an easier time
override them with their own styles.
It’s far too
Tab Atkins Jr. wrote:
details is definitely something we want to make fully
author-stylable.
I don’t. Who’s this ”we” you are talking about, and why do they want to make
details author-stylable even before a single browser has _any_ support to
the element, at the functional level?
Why
Tab Atkins Jr. wrote:
On Fri, Apr 8, 2011 at 12:30 PM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
Tab Atkins Jr. wrote:
details is definitely something we want to make fully
author-stylable.
I don’t. Who’s this ”we” you are talking about, and why do they want
to make details author
Lachlan Hunt wrote:
We would like our
implementations to be compatible as far as author styling is
concerned, and so it is very useful to discuss the fine-tuning of CSS
styling before we ship. If we did not do this, then you and every
other author would most certainly complain when Opera and
Wilhelm Joys Andersen wrote:
If there is no child summary element [of the details element], the
user agent should provide its own legend (e.g. Details). [1]
How exactly should this legend be provided?
Since the situation raises implementation difficulties, it would be best to
make the
James Graham wrote:
summary for=detailsIdThis is summary. Click to show/close
details./summary
div id=detailsId hidden.../div
That seems much harder for authors.
Not necessarily. The for=... attribute could be made optional, so that the
default association is to associate the summary
Aryeh Gregor wrote:
On Mon, Apr 11, 2011 at 11:58 AM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
Not necessarily. The for=... attribute could be made optional, so
that the default association is to associate the summary attribute
with the next sibling element.
(I wonder why the association
Nicola Di Fabrizio wrote:
is it possible to set a attribute for checking the element
if it is not empty
Yes, there's the attribute required, see
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-required-attribute
like
input type=text
I was surprised at seeing that the Finnish-language version of Google Chrome
11 beta accepts a number with a comma, such as 4,2, in input
type=number. It silently converts the comma to a full stop, 4.2.
This looked like a useful feature at first sight, as decimal comma is
standard in Finnish
Henri Sivonen wrote:
The the requirements you cite apply to what goes over the wire and
appears in the DOM. The browser may provide a comma-base UI for
manipulating the value that is stored and transfered using a period.
I see... thanks for the clarification. Yes the description is very
Looking at the nice summary (with examples) of text-level markup at
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#usage-summary
I started wondering why there is no example of markup for symbols of
physical quantities. The descriptions of individual
John Tamplin wrote:
The entire web application, which includes both client and
server-side code, must have the same idea about what locale the user
is using.
Well, HTML(5) is not just about client-server applications. It’s also about
offline applications and about the bulk of web and
Aryeh Gregor wrote:
So what markup should we use for E = mc², given that by the
applicable standards, E, M, and c should appear in italics and the
other characters as normal (upright)?
Those three characters are typeset, read, and otherwise presented
identically to variables, so the correct
Aryeh Gregor wrote:
I didn't read the whole thread, but: authors with specific needs will
always want to roll their own inputs for most of these things, and
that's fine.
An element for user input of a real number in a format that uses a suitable
decimal separator is hardly a specific need.
Edward Gerhold wrote:
I came to the conclusion, the cache is linked too tightly to the
manifest.
The manifest appears to be the heart of the matter, so by questioning its
tight connection to the application cache, you're questioning the
application cache itself. This may well be a good
Aryeh Gregor wrote:
On Sat, Apr 16, 2011 at 9:18 AM, Jukka K. Korpela
jkorp...@cs.tut.fi wrote:
An element for user input of a real number in a format that uses a
suitable decimal separator is hardly a specific need.
It's more specific than just an element for user input of a number
Ronny Orbach wrote:
I've researched hyperlink authoring
You seem to mean hyperlink _auditing_, specifically using the proposed
ping=... attribute.
which IMO is a great feature,
To me, it seems that it mostly generates the types of problems that it is
supposed to solve.
and it looks
Ian Hickson wrote:
I think we use [sic] as a way for one human to tell another human
that they are aware that the text has a mistake but that keeping the
mistake was intentional, so that the other human won't tell the first
human
to fix the problem. For this, plaintext [sic] seems to solve
14.5.2011 10:41, Boris Zbarsky wrote:
But why should this [wbr] override CSS that says do not break at any break
opportunities?
I don't think HTML specs should say whether it does; they should just
specify what wbr means, and in the case of rendering affected by CSS,
it's up to CSS specs to
2011-06-14 10:32, Ian Hickson wrote:
On Thu, 10 Mar 2011, Jukka K. Korpela wrote:
[...]
A sentence in the text may continue with list items, displayed e.g. as a
bulleted list. So the list breaks the paragraph as a block of text but
not logically - the list items are part of the sentence just
2011-06-15 3:26, Ian Hickson wrote:
Styling a whole document by having style sheets in the middle of the
document causes flickering (as the browser updates the styles),
Good point (though it's really may cause rather than causes.)
and is
hard to maintain. So we make this non-conforming, to
2011-07-01 11:26, Simon Pieters wrote:
Simon felt that “Content inside a blockquote must be quoted from
another source” excludes footer.
s/footer/attribution/
Indeed since it's a conformance requirement, in valid documents the
content inside blockquote is quoted from another source. If the
14.07.2011 13:49, Karl Dubost wrote:
using that for years (almost every day), an example
http://www.la-grange.net/2011/06/05/fruit
blockquote cite=urn:isbn:978-2-07-07533-7
pSur un pétale de lotus, j'écrivis ces quelques vers :/p
p«qMême si l'on vient me chercherbr/
Comment,
14.07.2011 16:10, Bjartur Thorlacius wrote:
Þann fim 14.júl 2011 11:09, skrifaði Jukka K. Korpela:
14.07.2011 13:49, Karl Dubost wrote:
blockquote cite=urn:isbn:978-2-07-07533-7
pSur un pétale de lotus, j'écrivis ces quelques vers :/p
p«qMême si l'on vient me chercherbr/
Comment, abandonnant
16.07.2011 00:01, Ian Hickson wrote:
Much discussion on this topic happened when we started on this work in
2004 and 2005, I highly recommend perusing the archives around that time.
Authors and implementors will need to be able to understand the topic
without checking discussions archives,
15.07.2011 19:56, Bjartur Thorlacius wrote:
On 7/15/11, Jukka K. Korpelajkorp...@cs.tut.fi wrote:
Should it? Even when the book has no URL? If you expect urn:isbn:… to
work anytime soon in any significant browser, you’re very optimistic.
Wikipedia and Amazon (among others) have all the
17.07.2011 18:07, Nils Dagsson Moskopp wrote:
But browsers need to be told that that number close to the quotation
is an ISBN.
The string “ISBN” is sufficient evidence of that.
Someone would need to standardize “ISBN sniffing behaviour” for UAs
then. Could you make a proposal?
I think it
18.07.2011 01:18, Bjartur Thorlacius wrote:
Titles of works are often more useful in the long run than URLs. URLs
change far too often when sites are revamped or for other reasons.
ISBNs are more useful in the long run than titles. Good titles get
reused far too often.
ISBNs have their uses
25.07.2011 22:02, Ian Hickson wrote:
So what markup should we use for E = mc�, given that by the applicable
standards, E, M, and c should appear in italics and the other characters as
normal (upright)?
It sounds like you want to use these characters:
U+1D438 MATHEMATICAL ITALIC CAPITAL E
28.07.2011 03:21, Ian Hickson wrote:
A text input field could have a number of error conditions:
Indeed. Therefore it would be essential to be able to set the error
message for _each_ check that a browser is supposed to do on the basis
of HTML markup alone. If this is not possible, it is
28.07.2011 12:16, Scott González wrote:
I agree that it's extremely important to be able to define error
messages per error condition, but it's not necessary to code all data
checking in JavaScript to achieve that today.
It's not, but if you cannot set the error messages in HTML, what's the
29.07.2011 20:05, Ian Hickson wrote:
The point is just
that u is used to explicitly annotate some text without saying why in a
textual manner. This makes it quite distinct from [sic], which is an
explicitly articulated annotation.
I fail to see how [sic] would be more explicit than
29.07.2011 23:56, Ian Hickson wrote:
Anyway, aren't you saying that u says this text is annotated but no
annotation is given? In that case, saying that u draws attention to
its content might be more appropriate.
The physical line is an annotation. It's just not articulated.
I think you
30.07.2011 01:39, Ian Hickson wrote:
On Sat, 30 Jul 2011, Jukka K. Korpela wrote:
29.07.2011 23:56, Ian Hickson wrote:
Anyway, aren't you saying thatu says this text is annotated but
no annotation is given? In that case, saying thatu draws
attention to its content might be more appropriate
Henri Sivonen wrote:
I don't know how niche thing it is to actually own a dedicated USB
barcode reader, but where I live, using at least one Web app that
supports bar code reading (by having a text input requiring the bar
code reader can emulate a keyboard) is as mainstream as Web app usage
Bjartur Thorlacius wrote:
Þann þri 2.ágú 2011 09:04, skrifaði Henri Sivonen:
[...]
From time to time, people want to take printed matter an
publish it on the Web. In practice, the formats available are PDF and
HTML. HTML works more nicely in browsers and for practical purposes
works
11.08.2011 00:10, Bjartur Thorlacius wrote:
On Sun, Aug 7, 2011 at 5:42 AM, Jukka K. Korpelajkorp...@cs.tut.fi wrote:
Bjartur Thorlacius wrote:
[...]
Please note that this isn't about favoring HTML over presentational markup
languages; none of the alternatives mentioned is a markup language
13.8.2011 16:52, Bjartur Thorlacius wrote:
My take on it is that implementations should interpret typographic
elements literally if descendants of q or blockquote, but as
optionally offset spans otherwise (i.e. optionally spoken in an
alternative mood, or rendered in an alternative font), using
28.8.2011 3:10, Nils Dagsson Moskopp wrote:
Bronislav Klučka bronislav.klu...@bauglir.com schrieb am Sun, 28 Aug
2011 01:56:15 +0200:
HTML5 defines several void elements.
I think this enumeration is insufficient, and I'd like to suggest to
simply allow every element to have syntax with / at
28.8.2011 17:52, Aryeh Gregor wrote:
Void is correct:
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#void-elements
I see. What a pointless and confusing change (from HTML tradition and
SGML usage). Empty is descriptive (an element that has no content, or
has empty
29.8.2011 13:10, Simon Pieters wrote:
In which way is void better than empty?
The sentence p/p is an empty element since it has no content, but p
is not an empty element. is more confusing.
More confusing than what? (Is that hypothetical sentence more confusing
than p/p is a void element
4.9.2011 9:14, Shaun Moss wrote:
I've joined this list to put forward the argument that there should be
elements for comment and ad included in the HTML5 spec.
IE recognized comment and ignored it in display, so it was like a
comment declaration (!-- ... --). It seems that they dropped
4.9.2011 23:27, Odin wrote:
We already have a comment tag. It's listed in the article-element
section of the spec. Article within article is suggested to be a
comment:
Suggested, not defined.
When article elements are nested, the inner article elements represent
articles that are in
6.9.2011 12:40, Benjamin Hawkes-Lewis wrote:
[S]elf-contained composition in a document, page, application, or
site and that is, in principle, independently distributable or
reusable, e.g. in syndication is a concept that includes comments,
blog posts, and news stories. So there's no
6.9.2011 18:43, Tab Atkins Jr. wrote:
If comments are generally self-contained compositions, what would be an
example of a composition that is _not_ self-contained?
A section of an article, for example.
I see no reason why a section of an article could not be self-contained.
For example,
6.9.2011 21:38, Benjamin Hawkes-Lewis wrote:
On Tue, Sep 6, 2011 at 4:28 PM, Jukka K. Korpelajkorp...@cs.tut.fi wrote:
[...]
We probably understand the words self-contained and independently very
differently then. I cannot see a typical comment as self-contained, as it by
definition implies
29.9.2011 20:34, Schalk Neethling wrote:
I heard some mention of using the data-* attributes so, something like:
a href= data-tooltip=Some help text/a
The data-* attributes are supposed to be strictly private, so they are
the last resort.
This all depends on what is going on, which was not
29.9.2011 20:50, Tantek Çelik wrote:
Javascript-only help text (tooltip or otherwise) or any other content
intended for human consumption is a really bad idea for all the usual
reasons
(#a11y, mobile, search etc.)
Except in cases where the information is relevant only when JavaScript
is
29.9.2011 21:52, Tantek Çelik wrote:
On Thu, Sep 29, 2011 at 11:12, Jukka K. Korpelajkorp...@cs.tut.fi wrote:
29.9.2011 20:50, Tantek Çelik wrote:
Javascript-only help text (tooltip or otherwise) or any other content
intended for human consumption is a really bad idea for all the usual
New elements like nav and footer have the problem that some existing
user agents don't recognize them, even for the purposes of styling. So
if you want to use nav, then - unless you're using it for purely
semantic reasons with no idea of styling - you need to use some special
trick to make old
26.10.2011 23:16, Tab Atkins Jr. wrote:
Believe me, these discussions were had in the past.
I do, but did you draw the conclusions?
All major UAs except old IE handle unknown elements in a way that's
acceptable
That means all browsers except that the most common one. Is that a
realistic
27.10.2011 0:57, Ashley Sheridan wrote:
If people are using versions of IE that old, then
they deserve to have an older version of the web given to them.
That's rather elitistic, given the fact that many people have no way of
upgrading their IE or switching to your preferred browser, and no
27.10.2011 5:38, Eric Sh. wrote:
And if we stop adding new features old browsers do not support or not use
them because very little browsers are not supporting them then it would
completely stop innovation and the evolution of the web.
How does this relate to the question of adding element
27.10.2011 9:55, Ashley Sheridan wrote:
There is no _required_ functionality or default rendering for nav or
article and no special attributes for them. What you lose by having
them as elements rather than attributes is that you cannot style them in
a manner that works on all browsers.
nav
27.10.2011 11:42, Simon Pieters wrote:
It's difference between working on all browsers and working on some
browsers as well as being tweakable when JavaScript is enabled.
div type=nav is not stylable in IE6 because it doesn't support
attribute selectors.
Granted, but
a) IE6 is dying,
27.10.2011 3:11, Ashley Sheridan wrote:
Try telling me
Google isn't aware of HTML5 in web pages and I'll laugh.
OK, I'll try: Google does not care about new HTML5 elements. Do you feel
amused now?
Can you please now do me, and others, a favor and give some evidence of
actual Google
30.10.2011 1:18, Eric Sh. wrote:
I heard there are plans to create new tags for layouts to replace the
use of tables as layout elements.
Maybe such rumors have been caused by taking some parody for real.
You keep speaking of creating new attributes instead of adding new tags
but then what
2011-12-01 1:28, Faruk Ates wrote:
My understanding is that all browsers* default to Western Latin (ISO-8859-1)
encoding by default (for Western-world downloads/OSes) due to legacy
content on the web.
Browsers default to various encodings, often windows-1252 (rather than
ISO-8859-1). They
2011-12-06 6:54, Leif Halvard Silli wrote:
Yeah, it would be a pity if it had already become an widespread
cargo-cult to - all at once - use HTML5 doctype without using UTF-8
*and* without using some encoding declaration *and* thus effectively
relying on the default locale encoding ... Who does
2011-12-06 15:59, NARUSE, Yui wrote:
(2011/12/06 17:39), Jukka K. Korpela wrote:
2011-12-06 6:54, Leif Halvard Silli wrote:
Yeah, it would be a pity if it had already become an widespread
cargo-cult to - all at once - use HTML5 doctype without using UTF-8
*and* without using some encoding
2011-12-06 22:58, Leif Halvard Silli write:
There is now a bug, and the editor says the outcome depends on a
browser vendor to ship it:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15076
Jukka K. Korpela Tue Dec 6 00:39:45 PST 2011
what is this proposed change to defaults supposed
2011-12-14 19:34, Ilhan Y. wrote:
By the way, can we have Unicode names (HTML names) for Mercury, Sun,
Earth and other planets. They are used by many astronomers on the
internet.
Nice parody! But maybe people won’t take it as parody.
After all, there is no rationale given for the inclusion
2012-01-03 12:45, Bronislav Klučka wrote:
On 3.1.2012 10:32, Mani wrote:
[…]
2. Will XHTML5 have a DTD, because XHTML5 must be well-formed?
http://www.w3.org/TR/html5/the-xhtml-syntax.html#writing-xhtml-documents
http://wiki.whatwg.org/wiki/HTML_vs._XHTML
To find an answer to the question
2012-01-20 1:19, David Singer wrote:
What the user enters and sees on screen is a presentational/locale issue
Which one? “Presentational” normally refers to things like layout
design, colors, fonts, and borders. Locales are something different.
The difference between “1.005” meaning one
2012-01-21 0:30, Ian Hickson wrote:
On Tue, 26 Jul 2011, Jukka K. Korpela wrote:
[...]
I don’t think you have clarified whether var is suitable for
physical quantities, but I guess you meant to imply it—even though
there is not a single example about markup for physical quantities.
Given
2012-01-24 1:18, Ian Hickson wrote:
u, for instance, was only added after rather
compelling use cases were presented.
The only use cases mentioned in the current version of the living
standard are labeling the text as being a proper name in Chinese text
(a Chinese proper name mark) and
2012-01-27 21:33, Ian Hickson wrote:
On Wed, 26 Oct 2011, Jukka K. Korpela wrote:
New elements likenav andfooter have the problem that some existing
user agents don't recognize them, even for the purposes of styling.
This is only a transient problem for a few years, and a minor one
2012-02-10 12:39, brenton strine wrote:
Regarding the an input with type in the number state, the spec states
that the pattern attribute must not be specified and do[es] not
apply to the element.
That’s because the pattern attribute is for constraining text data using
a regular expression.
2012-02-12 2:13, Ian Hickson wrote:
That's not to say that one day we won't provide an explicit way to mark up
attribution for blockquotes in markup, just that the desired
presentation isn't a relevant concern in doing so
The relationship between a quotation and the indication of source is
2012-02-12 8:36, Nils Dagsson Moskopp wrote:
Why do you hate the cite attribute?
I don’t; it’s just useless, and it does not in any way satisfy the
legal, moral, and scholarly requirements for specifying the source.
Seldom does an author wish to quote an entire section. It is not even
2012-02-12 8:36, Nils Dagsson Moskopp wrote:
Since in current usage, blockquote means just “indent” more often
than not, browsers and search engines should not and will not imply
any specific semantics for it. Thus it will be pointless to use it.
Riveting tale, chap. Can you provide proof?
2012-02-12 19:54, Ian Hickson wrote:
The blockquote has been, and will be, rather pointless without markup
for “credits” (indication of author and source, which are normally
required by law).
What's the use case, other than presentation?
What’s the use case for markup for quotations in
2012-02-12 21:43, Nils Dagsson Moskopp wrote:
The difference between blockquote and (for example) quotation as
quotation markup is that the latter has no burden of existing use for
other purposes.
By analogy, a completely new table element would also be necessary.
There has been quite a
2012-02-12 23:25, Ian Hickson wrote:
The use case for most of the semantic markup is jsut easier authoring
and maintenance, in particular for selectors in CSS.
If that’s the approach, and this reflects a consensus, shouldn’t this be
explained in the introductory material (which is now rather
2012-02-22 19:30, Cameron Jones wrote:
Updatingoutput as form submittable element is included in a
proposal to enhance http request processing under a w3c issue
This sounds like a pointless attempt at enhancing a pointless element.
Instead of output, authors can use, and have been able to
2012-02-22 20:13, Cameron Jones wrote:
It [the output element]
does provide a greater degree of integration with the browser though.
Is this a requirement, or just assumed features of implementation? Which
of the assumed benefits could not be achieved by adding a new value for
the type
2012-02-22 20:38, Cameron Jones wrote:
I'm referring to the for attribute onoutput which ties its value
to the elements which went into the calculation. This would otherwise
have to be done using event attributes.
I don't see how that is supposed to simplify things. It's supposed to
2012-03-29 22:02, Matthew Nuzum wrote:
Hello, on every HTTP request your browser sends header called
Accept-Language with a value something like this:
en-gb,en-us;q=0.7,en;q=0.3
– –
Browsers support a value called navigator.language but it does not
convey the same information as the
1 - 100 of 170 matches
Mail list logo
