'rel' on links.
http://www.microformats.org/blog/2005/10/19/more-than-styling/
http://microformats.org/wiki/hcalendar
http://microformats.org/wiki/xoxo
As Tantek likes to remind people: don't reinvent.
~fantasai
writing gotos.
~fantasai
, too.
~fantasai
/pipermail/whatwg-whatwg.org/2005-
August/004649.html
Something else to think about: If cite is reserved only for source
citations, what markup do we use for generic title of work?
~fantasai
engineers I know.
As for spelling, I'm likely to use gage for e.g. 22-gage steel deck,
but I'm inclined to use gauge for fuel gauge. But that's just me.
~fantasai
Ian Hickson wrote:
On Tue, 28 Mar 2006, fantasai wrote:
Another issue is the possible use of U+2212 MINUS SIGN intead of U+002D
HYPHEN-MINUS. This last, at least, should be handled whenever the number
is parsed from the text content rather than in an attribute.
In the text, negative
Henri Sivonen wrote:
Single select:
Is it conforming for an option to be both selected and disabled? (I
think it shouldn't be conforming.)
I agree with that.
And analogously: Is is conforming for a radio button to be both checked
and disabled if the whole set is not disabled? (This one is
there are, other tools do. We can't
express IDness in a schema if we insist on ignoring its syntactic
restrictions.
~fantasai
Henri Sivonen wrote:
On Apr 2, 2006, at 18:56, fantasai wrote:
I'd rather see the id attribute restricted to an NCName token insofar
as possible. We can make an exception for Hixie's repetition templates,
but otherwise I think it should be compatible with the XML ID syntax.
Do you mean
-users/message/422
Does moving the choice up higher help any?
~fantasai
Ian Hickson wrote:
On Tue, 4 Apr 2006, fantasai wrote:
I'm wondering what WA1 considers appropriate markup for a figure with a
caption.
pimg src=image-equivalent-of-text alt=text title=caption/p
As Lachlan points out, putting caption text in an attribute isn't very
good design
.
~fantasai
from the locale.
What locale?
~fantasai
/tables.html#h-11.4.1
~fantasai
2.1 draft in particular?
Easy: it didn't get removed.
http://www.w3.org/TR/CSS2/tables.html#q7
~fantasai
that is a stronger argument for keeping char than align.
Another argument for align is that CSS alone can't do anything useful
about alignment in columns, since inheritance only works through the
element tree. Of course, I'd prefer to see that fixed in CSS.
~fantasai
, albeit without the captions:
http://www.mozilla.org/contribute/writing/markup#notes
~fantasai
contains the definition for the _term_ of
the dfn element.
I'd just strike the contents.
definition for the term given by the dfn element.
~fantasai
/ltdef.html#index
[2] http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html#top
~fantasai
be the most appropriate default feed to subscribe to
from an entry page, if it were somehow clearly labelled.
~fantasai
=[atom]
and without dropping the 'type' attribute entirely (which was the other
solution pointed out on the whatwg list).
~fantasai
. The key difference from other annotation systems is that it can be
word-for-word without being awkward. (Imagine doing this with footnotes.)
~fantasai
is that their presentation is the same, but that argument doesn't
hold up for non-Latin texts. Restyling em sitewide to use 'text-emphasis'
instead of 'font-style: italic' would be a nifty thing on a Japanese website.
Restyling i the same way would just be silly.
~fantasai
it easy to cut out
extraneous content and print just the main content of a web page.
~fantasai
:
http://microformats.org/wiki/datetime-design-pattern
The time element is much more appropriate for this than abbr.
[1] http://code.google.com/webstats/2005-12/classes.html
~fantasai
Benjamin Hawkes-Lewis wrote:
An author element might kill several of these birds with one stone.
I'd rather see an attribution element than an author element.
It is more generally useful.
~fantasai
and limitations. Trying to constrain their use is imho unwise.
When Tantek Çelik comes to the WHATWG or the HTMLWG and says I want a central
registry for class names, then make one. Until then, I suggest simply leaving
this domain to the μF guys (and gals).
~fantasai
on a lot of sites if the author just bothers to put
it there. Of course the author could make the print result pretty, rather
than just a text dump. There are very few cases where a separate document
would be necessary.
~fantasai
Nikola Mitic wrote:
fantasai wrote:
Michael wrote (on www-style):
I have a fluid layout so it changes width because of the browser window.
There is the slight problem that some of the images I use might be too wide.
So I use max-width:100% to prevent this from happening. This works great
is adequate.)
~fantasai
to be side-by-side with the original page: in that case a
floating box in the middle of the page would be ideal. Etc.
~fantasai
. For some background,
you can see the relevant discussions for CSS
http://www.w3.org/blog/CSS/2007/12/12/case_sensitivity
~fantasai
a size can be considered a relationship.
I don't think it can. This seems pretty wrong to me: the right place for
this information would be, as Jeff Walden said, in the 'type' attribute.
~fantasai
probably want the ability to specify a ratio instead.
(And I suppose for sound icons, you'd want the length of the sound clip...)
Also, I didn't see anything in the spec about parameters needing to be
prefixed, only subtypes. Maybe I missed it.
~fantasai
a similar problem.
~fantasai
. ...
You could use dialogue instead of dialog. Dialog is an alternate spelling
of dialogue in common English, but IIRC dialogue is never used for dialog
boxes. I'm sure mpt can correct me if I'm wrong...
~fantasai
: in many cases certain carefully-chosen strokes are left out in
the smaller sizes in order to make it legible. Judging from information
about Meiryo, it seems more recent font technology uses vectors + hinting
to solve the same problem... but maybe it's something to keep in mind.
~fantasai
these elements won't be reading the spec.
It is quite likely that someone will assume dialog is the correct
tag to use for a CSS+JS dialog box.
~fantasai
Ian Hickson wrote:
On Wed, 11 Feb 2009, fantasai wrote:
Given the state of current implementations and the fact that hidden input
elements do have distinct enabled and disabled states, I don't understand
the reasoning behind this change.
http://twitter.com/WHATWG/status/1198455588
The idea
for these attributes here:
http://fantasai.inkedblade.net/markup/tests/table-frame-rules/
I should probably expand it to include tests for the empty string and junk
valuse, but that's what it is for now.
~fantasai
Ian Hickson wrote:
On Mon, 4 May 2009, fantasai wrote:
Section 10.2.6, i.e. The XHTML syntax: Rendering: Punctuation and decoration
contains some style rules for handling the [rules] and [frames] attributes
of the table element. I haven't reviewed it all in detail but this part
table[frames
On 01/14/2010 12:49 AM, Simon Montagu wrote:
On 01/11/2010 11:35 PM, fantasai wrote:
On 11/26/2009 10:54 PM, Simon Montagu wrote:
I assume your Gecko example is using a very recent version of Gecko,
such as a nightly build or a beta of Firefox 3.6? I fixed this issue
only a few months ago
filed as something to look at for Selectors 4.
~fantasai
, which is equivalent to
naming large features of HTML.
How do you define a large feature of HTML?
~fantasai
. And if there is behavior to
activate, it should be keyboard-activateable as well, not just mouse-
clickable.
I'm also interested to know whether there's a web-compat issue here or
just a bug-compat issue, and what the implementers think.
~fantasai
. If implementers want to take that on, it can be part of CSS3
Text. Also there were proposals for a text-outline property, which would
do something similar, based on feedback from the TimedText WG.
http://www.w3.org/TR/css3-text/#text-shadow
http://www.w3.org/TR/css3-text/#text-outline
~fantasai
with the rendering requirements by
specifying
wbr { content: '\8203' /* zwsp */;
text-wrap: normal; }
Slightly off-topic: in CSS3, there is an 'avoid' value for 'text-wrap',
which is designed to solve problems similar to those currently dealt
with by using nobr/wbr combinations.
~fantasai
option.
~fantasai
...@w3.org,
with [mediaqueries] in the subject line.
~fantasai
so that we don't miss your comments.
Thanks~
~fantasai
at *least* 15 minutes to respond? No? :-)
http://krijnhoetmer.nl/irc-logs/css/20120114
In the interests of moving on with this, I've changed the spec to the
above. I welcome implementation experience on whether this works. If it
doesn't, I'm happy to change it back.
Sounds okay to me.
~fantasai
that we're considering a pseudo-
element here?
~fantasai
, they are all equivalent. For things like credit card numbers
and postal codes, they probably aren't.
The spec could perhaps benefit from an example of how /not/ to use
type=number here...
~fantasai
=CSScomponent=Flexboxresolution=---
[2] http://lists.w3.org/Archives/Public/www-style/
~fantasai
Co-Editor, CSS Flexible Box Layout
:valid-drop
:no-drop:no-drop :invalid-drop:invalid-drop
Thanks~
~fantasai
On 08/13/2012 11:55 PM, Ryosuke Niwa wrote:
On Mon, Aug 13, 2012 at 9:19 PM, fantasai fantasai.li...@inkedblade.net
mailto:fantasai.li...@inkedblade.net wrote:
The CSSWG discussed drag-and-drop pseudo-classes today. The current
proposal is to have three pseudo-classes:
* One
as :not(:valid-drop). I'm unsure if
it's necessary to add at this point, but can add it and mark at-risk for
the time being.
~fantasai
On 11/16/2012 07:38 AM, frederick.hir...@nokia.com wrote:
fantasai
Is the WG response (see below) to your Last Call issue (LC-2642) [1]
on HTML Media Capture [2] regarding clarification of accept and capture
[attributes of input] sufficient for us to close the issue?
If timeless and/or hixie
IIRC is 'none'.
I'm not sure I'd recommend it as a good way forward for anything
since it's not clear how other values are supposed to work.
~fantasai
WG,
~fantasai
how to specific audio
characteristics in a media query.
I don't think such a thing exists, but you could request it
for Media Queries Level 4:
http://dev.w3.org/csswg/mediaqueries4/
You'd want to post to www-style for that, though.
~fantasai
line with
[css-cascade-3]
(as I did on this message). The deadline for comments is
** 26 August 2013 **
Please let us know if you need an extension.
We would particularly appreciate review of this module from the
HTML and WebAPI communities. Thanks!
For the CSS WG,
~fantasai
=13108
I've no comment on concerns about compatibility with XML, but I can say
that I've typed zwsp; multiple times expecting it to work and find it
surprising that zwj; and zwnj; work, but zwsp; does not...
~fantasai
came up on the
CSSWG ML just recently:
http://lists.w3.org/Archives/Public/www-style/2014Jul/0131.html
In that case it's about retrieving the OS's notion of this color.
~fantasai
, not being a longhand of 'display', will stay
separate.)
For the CSS WG,
~fantasai
de-4]
(as I did on this message).
For the CSS WG,
~fantasai
them to <www-st...@w3.org>, prefixed with [css-pseudo-4]
(as I did on this message).
For the CSS WG,
~fantasai
On 06/20/2016 06:14 PM, Phillips, Addison wrote:
+I18N Core
Thanks for this. I have added this to I18N's radar [1]. Do you have a
due date for comments in mind? Or a general schedule?
Not really.
~fantasai
in the CSSWG GitHub repository at
https://github.com/w3c/csswg-drafts/issues
For the CSS WG,
~fantasai
On 02/02/2017 01:18 PM, Boris Zbarsky wrote:
On 2/1/17 6:07 PM, fantasai wrote:
Wrt this particular issue, run-ins only run into other blocks; they
do not exist in or affect layout modes other than block-and-inline.
OK, so if I have a flex container with two kids, a run-in and a block, do I
.
Wrt this particular issue, run-ins only run into other blocks; they
do not exist in or affect layout modes other than block-and-inline.
~fantasai
ith [css-display] (as I did on this message)
or (preferably) file them in the GitHub repository at
https://github.com/w3c/csswg-drafts/issues
For the CSS WG,
~fantasai
:38 PM, fantasai wrote:
First one is 'display: contents':
This one is mostly a question for Mats. That said, I think this
feature adds a huge amount of complexity, and I expect that some
of its interactions with HTML are not very clearly specced. For
example, what should this do
I did on this
message) or (preferably) file them in the GitHub repository at
https://github.com/w3c/csswg-drafts/issues
For the CSS WG,
~fantasai
he CSS WG,
~fantasai
On 12/25/2017 02:54 AM, fantasai wrote:
The CSS WG has published an updated Candidate Recommendation of the
CSS Scroll Snapping Module Level 1:
https://www.w3.org/TR/css-scroll-snap-1/
This module contains features to control panning and scrolling behavior
with “snap positions
list,
, prefixed with [css-display] (as I did on this
message) or (preferably) file them in the GitHub repository at
https://github.com/w3c/csswg-drafts/issues
For the CSS WG,
~fantasai
-drafts/issues/1771
It's tagged against Level 4, but we did just add handling for
and .
~fantasai
Forwarded Message
https://lists.w3.org/Archives/Public/www-style/2018Mar/0001.html
The CSS WG has published an updated Working Draft of the
CSS Intrinsic and Extrinsic Sizing Module
://github.com/w3c/csswg-drafts/issues/2263
Please review the draft, and send any comments to the CSSWG mailing list,
, prefixed with [selectors-4] (as I did on this
message) or (preferably) file them in the GitHub repository at
https://github.com/w3c/csswg-drafts/issues
For the CSS WG,
~fantasai
On 11/21/18 2:33 PM, Andrew Fedoniouk wrote:
:blank is quite bad as a state name
For example shall be considered as not :blank as it has initial value
deliberately set to blank string (empty string allowed).
This would match :blank.
~fantasai
Emilio Cobos Álvarez)
for their detailed feedback this round.
Please review the draft, and send any comments to the www-style mailing list,
, prefixed with [css-lists-3] (as I did on this message) or
(preferably) file them in the GitHub repository at
https://github.com/w3c/csswg-drafts/issues
For the CSS WG,
~fantasai
repository at
https://github.com/w3c/csswg-drafts/issues
For the CSS WG,
~fantasai
on its proposals prior to deciding to ship, would be better than the
circumvention of the standardization processes *and spirit* being demonstrated
here, I would think.
~fantasai
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
1 - 100 of 125 matches
Mail list logo
