Jukka K. Korpela wrote:
On Thu, 31 Mar 2005, fantasai wrote:
What Jukka's trying to say is, attribute minimalization in SGML -- which
lets you do things like
input type=checkbox checked
doesn't let you leave out the name of the attribute -- it lets you leave
out the *value*.
Of course, you
inside retain the same relative semantics.
~fantasai
within pre; block-level distinctions within
preformatted text (such as plaintext emails) are given by the previous
formatting (e.g. whitespace).
(Yes, I meant 'e.g.'; C code is preformatted, too, but its block level
distinctions are given by braces and the like.)
~fantasai
it, then it already passes CR criteria.
Besides, you shouldn't be obsoleting things without letting them go through
the deprecation stage. No?
~fantasai
think you
can. If you change the presentation of sub you _do_ change the perceived
meaning of the rendered content.
Subscripts can be marked with brackets when subscripting isn't available.
Superscripts can likewise be done with ^. But it's not ideal.
~fantasai
attribute of some kind if you are to handle the
different typographic conventions for e.g. books vs. articles. Book
titles are italicized: article titles are put in quotes. Parallel
distinctions exist for other types of creative works.
~fantasai
) to the public network.
For those of us writing HTML by hand, this is not a practical solution,
particularly when invisible characters are involved. Invisible characters
aside, I don't want to go digging through a Unicode character map every
time I want rarr; or tau;.
~fantasai
example from the spec.
~fantasai
the ice with feed then RSS 1.0 wins.
'feed' is not really defining a /relation/, it's defining a sort of
meta-content-type... But I would much prefer that to forcing 'alternate'
on non-'alternate' links.
~fantasai
(Copying to WHATWG mailing list: http://www.whatwg.org/ )
,
don't follow it.
That neatly describes the link functionality in a set of known terms,
and avoid a lot of the mess with prefetching...
rel=nofollow means this link is not endorsed, not don't follow this
link.
~fantasai
forget where..)
General
---
Overall, I'm really, really impressed with what you've done here.
One nit: Please provide actual titles for the sections (as I have
done here) rather than just putting the element name. (But don't
leave out the element name either.)
~fantasai
#it is generally felt authors are more familiar with the term URL
#than the other, more technically correct terms.
Does this allow relative urls? Please specify explicitly.
~fantasai
Ian Hickson wrote:
On Mon, 27 Jun 2005, fantasai wrote:
# url
#An IRI, as defined by [RFC3987] (the IRI token, defined in RFC 3987
#section 2.2). UAs could, for example, offer the user URIs from his
#bookmarks. (See below for notes on IDN.) The value is called url (as
#opposed
Ian Hickson wrote:
On Fri, 1 Jul 2005, fantasai wrote:
I'd like to suggest that ID attributes use a different syntax than [] to
mark repetition placeholders, one that fits with the XML restrictions on
IDs. The current syntax makes it impossible to define ID attributes as
type ID in any
Ian Hickson wrote:
On Fri, 1 Jul 2005, fantasai wrote:
I'd like to suggest that ID attributes use a different syntax than [] to
mark repetition placeholders, one that fits with the XML restrictions on
IDs. The current syntax makes it impossible to define ID attributes as
type ID in any
, that will be the least of their problems.
No, fantasai is right, I can see this being a FAQ, for no obvious
technical reason.
You seriously think that nested templates will be common enough for this
to be a FAQ? Wow. A few months ago people were saying that this would be
so rarely used that we should take
Ian Hickson wrote:
On Mon, 4 Jul 2005, fantasai wrote:
Now my question is, what if you need to define the same term twice?
E.g.
In CSS, a dfnproperty/dfn is ...
However, in XXX, a dfnproperty/dfn is ...
Give the two different title attributes.
You mean, like
dfn title=CSS property
you are all
in agreement as to what advice you want to give web authors
wrt this issue.
~fantasai
Ian Hickson wrote:
On Wed, 6 Jul 2005, fantasai wrote:
Two points:
1. The 'scheme' attribute from HTML 4 is missing. If there's
a reason for this, please include a note stating the reason
for removal (and thereby make the removal explict). Note that
certain metadata formats (e.g
understand correctly, HTTP headers aren't quite so particular about
whitespace. Do you intend to require that exact sequence of characters,
or would, for example, removing the space after the semicolon or using
three spaces there also be acceptable?
~fantasai
of the
document's paragraphs directly.
~fantasai
could go in which 'rev' would be useful.
Many of the link types suggested there would be easier to use with
rev for the reverse link than with a separate keyword that means
the inverse relationship.
Example:
rev=refutation to link to the article one is refuting
~fantasai
of the style element as the style.
Are HTML documents allowed to use such XML-based styling languages in
the style element as well?
~fantasai
In HTML 4, the 'href' attribute of the base element is #REQUIRED.
Is there a reason why in HTML 5 it is not required?
~fantasai
Ian Hickson wrote:
On Mon, 18 Jul 2005, fantasai wrote:
In HTML 4, the 'href' attribute of the base element is #REQUIRED.
Is there a reason why in HTML 5 it is not required?
What's the point in making it required?
What's the point in making the img element's 'src' attribute required
Ian Hickson wrote:
On Mon, 18 Jul 2005, fantasai wrote:
HTML 4 #REQUIREs the 'content' attribute for meta. It does not require
'name' probably only because the DTD can't express a requirement of
either 'name' or 'http-equiv': as WA1 notes, a meta element without
a 'name' attribute isn't
L. David Baron wrote:
On Monday 2005-07-18 08:44 -0400, fantasai wrote:
In HTML 4, the 'href' attribute of the base element is #REQUIRED.
Is there a reason why in HTML 5 it is not required?
base target=foo is pretty common on pages that use frames. Then
again, the web apps spec doesn't
Ian Hickson wrote:
On Mon, 18 Jul 2005, fantasai wrote:
Ian Hickson wrote:
On Mon, 18 Jul 2005, fantasai wrote:
HTML 4 #REQUIREs the 'content' attribute for meta. It does not
require 'name' probably only because the DTD can't express a
requirement of either 'name' or 'http-equiv': as WA1
:
| meta name=refuting content=
| Intelligent Design;
| http://hemadeyou.org
|
I don't think I need to say anything about how ridiculous a counter-
suggestion that is.
~fantasai
items in lists or cells in
tables.
But that's a presentation issue. The list is semantically empty, it just
happens to have Nothing to do rendered in its place. IMHO.
FWIW, I agree with Ian here.
~fantasai
, represent nothing. They do not even
provide any structural semantics as div and span do; the document
has the same semantics as if the element did not exist.
~fantasai
is allowed in xHTML 5?
~fantasai
through the H section of her English-Chinese dictionary, it being
the only dictionary on hand around here*
How about Hint tRansition?
Other semi-useful H words include: hold, hook, horizon ...
Hint seems the most appropriate, I think.
~fantasai
.
?
~fantasai
elements and heading structure in
particular seem to address this problem. If you have suggestions for
improvement, of course you are strongly encouraged to comment on the
mailing list.
http://www.whatwg.org/specs/web-apps/current-work/#sections
http://www.whatwg.org/mailing-list
~fantasai
Why do code and samp allow structured inline content while kbd only
allows strictly inline content?
~fantasai
of the previous item plus one.
(Either way, you should remove the comma before plus one.)
~fantasai
The header and footer elements don't allow any sectioning elements,
which includes blockquote. However, headers and footers sometimes
include a short (but not inline) epigraph. How would you mark that
up?
~fantasai
coordinate system scales when an image
is stretched or shrunk via CSS.
~fantasai
an absolute URI to a relative
one later on.
~fantasai
(naming
with the id attribute).
The A element no longer has a name attribute in HTML 5; the 'id'
attribute is a much better design, and is already well supported.
http://www.whatwg.org/specs/web-apps/current-work/#the-a
~fantasai
Matthew Raymond wrote:
How many user agents support Javascript but not CSS1? Does Lynx or
some other text-mode browser support Javascript? I'll have to look into
that...
ELinks is experimenting with SpiderMonkey.
~fantasai
42 matches
Mail list logo
