“presentational hooks for content”??
That sentence smells totally blue like sunflowers. There’s no such thing as a “presentational hook for content”.
I’ll bet some code examples would make a lot more sense.
No. If it has content in it then it is semantically a part of the document usually with the id or class identifying its semantic meaning.
It is only a hook if its purpose in being there is to make up for deficiencies in browser support of CSS and so additional “meaningless” tags are required in the HTML in order to be able to produce the desired appearance. This reflects a deficiency in the CSS language where you are forced to use HTML (or JavaScript) to make up for that deficiency even though it really ought to be done entirely in the CSS. A hook is tthere in the HTML purely for the purpose of hanging some CSS on it that can’t be attached into the HTML any other way.
Well XHTML doesn’t work in any version of IE prior to IE9 and so if you use XHTML you immediately discard all of your possible visitors who insist on using IE8 or earlier.
XHTML will demonstrate its full power once IE8 is dead as those browsers are yet to support the 1999 standard that introduced XHTML
Christmas on a cracker, that’s your idea of “violent language”?!? Mein gott are people REALLY this thin skinned out there? (the mind boggles)
As to spinning what you say, with the broken engrish its a bloody miracle anyone can even make sense of any of your posts - most of which appear to be total gibberish.
Off Topic:
Just exactly where are you from that you reverse all your verb-noun structures and use the incorrect tense on everything? I’m suspecting oriental origin, though you are way too thin skinned for mainland. Japan perhaps? Tada atezuppō no kokoro o…
How exactly is using them for WHAT THEY ARE FOR abuse?
http://www.w3.org/TR/html4/struct/global.html#edef-DIV
It’s WHAT IT’S FOR!!!
Just because you’re using a div as a hook doesn’t make it abuse; Where the devil you even got the mere NOTION that it is such is… I lack the words in polite company.
Rights? What rights… ah crudstunk, another of these nutjobs. Lemme guess, you worship at the Church of Stallman as well? Though once again I might simply be completely misunderstanding what you are saying… Every time I see someone throw the word ‘rights’ into a discussion like this (or any discussion really) I always kneejerk into “great, someone else with a sense of entitlement” as if we’re magically entitled to things or treatments… We aren’t.
It’s completely valid in strict, it is WHAT they are FOR… You know the real comedy about this is, I’m the one usually telling people “that div is unneccessary”. I’m failing to see how using the tag for WHAT IT IS FOR is abuse!?! That’s the dumbest thing I’ve ever heard!
If by near future you mean the decade or so from now when CSS3 hits recommendation status and IE8 is a long-gone memory; and even then there are still things CSS3 can’t actually do… Hell, most of the stuff I do in designs CSS3 doesn’t do to my satisfaction… and since I can do it just fine without it I’m not certain I see the point; Especially when the pages I code are usually have half the total markup of everybody elses.
Though I see once again you are avoiding the real world example question posed; Just as in the other thread you suddenly ‘stopped working’ on it because actually doing what the person wanted would have completely contradicted your ‘views’.
Transitional is ONLY for when you are still using presentational HTML 3.2 tags that you have not yet finished cleaning up. Once they are cleaned up then using strict IS the appropriate doctype. You may still have further things to clean up to make your HTML perfect but once it validates as HTML 4 strict then that is thr right doctype to use.
To get the sort of thing you are talking about requires HTML standards for web page authors and no such official standards exist. The only standards that the W3C produce are for the web browser creators to define the basic level the browser should understand. The doctype identifies the level you expect the browser to support.
There is no identifier in the web page to specify what standards you are following in writing the web page beyond that which identifies the basic level you expect the browser to support. The only way of adding that information is via comments.
Trying to use an incorrect doctype in order to identify that the page content does not meet some specific in-house standard for semantics of your HTML is going to create problems since there are other things impacted by changing between a strict and transitional doctype that have nothing to do with the HTML due to browsers also using it for other things.
HTML 4 transitional relates 100% to the HTML 3.2 tags that it supports which have been declared to be obsolete in HTML 4 (and thus are marked as deprecated). If your page does not use any of those tags and only uses those in HTML 4 even if it uses all of them incorrectly then your page is still HTML 4 strict since that doctype relates only to what tags you use and not to how you use them.
Misusing the doctype is a million times worse than misusing any other tag.
You can do all those things while still having the page validate as strict.
The transitional doctype is specifically there to indicate that the page contains HTML 3.2 elements that have yet to be replaces and that does NOT apply in this situation.
There are actually at least three different versions of HTML that an HTML 4 strict doctype applies to.
-
The actual HTML 4 standards that the browsers need to impose in order to consider the web page to be HTML 4 - basically any page that validates as HTML 4 strict and also follows the few extra rules that the validator can’t check for (such as form fields having a wrapper around them with the form wrapped around that).
-
Pages that both follow the standards and areitten semantically with as few as possible extra div and span tags as are needed to work around the current limitations of CSS.
-
Pages that are fully semantic without any extra hooks provided just to allow the presentation to work.
None of these three are HTML 4 transitional, they are all HTML 4 strict and just vary in how they apply the HTML 4 strict rules. Perhaps what is needed is and additional marker at the top of the file to indicate which of these variants of HTML 4 strict that the page uses so that you know which pages that you need to cme back to and change once the CSS issues are resolved. This could be done by adding a comment after the doctype to indicate which level of HTML 4 strict is being applied.
<!-- basic–>
<!-- semantic plus hooks ->>
<!-- fully semantic –>
These would be the three levels to aim for when moving away from transitional and getting rid of the last of your HTML 3.2 tags (even if that is just to replace it temporarily with inline styles as a step along the way).
The reason why there are no separate variants of the doctype for these three levels of compliance is that the standards are aimed at the browser writers as to what the browsers need to support and no generally accepted standards exist to fully define these levels for the web page authors. While individual sites may have these standards defined for their own internal use the specifics of their standards may differ slightly from those used by other sites.
There are really two different groups that need standards - those creating the browsers and those creating the web pages. The standards we have are for those creating the browsers. The HTML 4 strict standard is what browsers need to support in HTML if the web pages are correctly coded by those writing the web pages. The standard that those writing the web pages should be following needs to include a LOT of additional things that the standards that we have do not specify since it was decided that the browser should be able to handle minor errors such as leaving out certain tags (labelled as optional in the standard but which will just generate problems if you actually do leave them out).
The only reason that the transition doctype exists is that prior to about 2005 it wasn’t possible to really try to follow the strict doctype as there were still popular browsers that didn’t understand enough CSS. Unfortunately that means that those of us who wrote web pages before then still have a huge mess to finish cleaning up in our pages to get rid of all the HTML 3.2 presentational tags we had to use when we originally wrote the pages. Those months of effort would not have been necessary if browsers hadn’t introduced those stupid tags in the first place. There is no reason apart from ignorance for anyone to select a transitional doctype and make a future maintenance nightmare for themselves now though although once CSS 3 is fully supported there will be further cleanup of the HTML 4 that will be possible as then the standards that the web pages should follow will have changed further. The standard that the browser writers will still need to follow will still be HTML 4 strict though so as to both allow time for the conversion plus because that standard doesn’t deal with the sorts of changes that will be required to the HTML.
As I read through this thread, I could only think that noonnope has a complete misunderstanding of what a DTD is, and the other commenters were drawn offside by his arguments; until Stevie D’s comment addressed the underlying issue.
The DTD is a statement of the language’s grammar, or syntax. The DTD has no concern with the content or its meaning; only that the markup is used correctly by its rules. Semantic markup is about choosing the best element tags according to the what of the content’s existence. The DTD doesn’t care as long as the syntax is correct. As far as the DTD is concerned, a list (for example) could be marked up as a bunch of p, div, span, cite, or abbr elements, or not marked at all (as comma separated values, e.g.). Just be sure whatever markup you choose, no matter how nonsensical, follows the grammar, and it will be valid.
Where noonnope got off track is in confusing the DTD and best practice. Where the others followed the derailment is in discussing best practice in terms of the DTD. Let us assume the markup is valid, and resume the discussion as one about practices, and leave the DTD out of it. Or, if the DTD is still in question, the answer is, use the DTD that defines the grammar you intend to follow. That’s it.
cheers,
gary
WRONG – why Wrong?
Because there are no best practices for Tranny; because by definition transitional lets you use attributes like TARGET and tags like FONT and CENTER which are INHERENTLY bad practices.
You’re talking about DIV and SPAN as hooks as if they were bad practices; THEY AREN’T!!! You might be uncomfortable with them, but they are currently the best practice for accomplishing most of the effects people want on pages… especially since they have zero impact in changing the meaning of the tags they are around.
It’s what DIV and SPAN EXIST FOR! We need those hooks, and even CSS3 won’t get rid of them completely (try doing transparent corners without a extra wrapper using :after – you still need a relative PARENT; and double backgrounds won’t do sliding doors with transparency either)
Seriously, sliding doors transparent image corners – try doing it even with CSS3. The ‘rounded corners’ code might not do the shape or pattern you want and is inconsistent cross browser, multiple backgrounds will overlap so you can’t use those, :before or :after would take an extra wrapping parent element (like a div) to absolute position off of since they can’t position off their immediate parent (why I think we need :beforeEnd and :afterBeginning or some such), so what’s the “best practice” that won’t effect the existing semantic markup?
A DIV inside a DIV or a SPAN inside a H# tag, margin-right on the parent and absolute positioning on the inner element. Even CSS3 falls a bit short on pulling off what should be a simple effect.
You might go screaming “AAAH, DIV’s AAAAAAAH!!!” – GET OVER IT! It’s still not presentational markup since without CSS there’s no presentation APPLIED. That’s the difference between DIV/SPAN and CENTER/FONT/BASEFONT/BGCOLOR/COLOR etc, etc, etc…
Advocating transitional just because you don’t like sandbags and wrappers as styling hooks misses what STRICT is about; removing tags we don’t need or shouldn’t be using… and frankly, DIV and SPAN don’t qualify under ANY of the categories of tags STRICT removed; APPLIED Presentation (CENTER, FONT, BGCOLOR), Redundancy (MENU, DIR), or just piss poor accessibility (iFRAME, TARGET)…
You don’t like DIV and SPAN; Whatever. Dumbest thing I’ve seen on a web development forums in a decade - and I’ve seen some STUPID MALFING CRAP out there. (Microformats, Jquery, WYSIWYGS…)
I could agree with that except it’s based on false assumptions and reads WAY too much meaning into the specification; To the point of stuffing words in it’s mouth that have nothing to do with the POINT of semantic markup, separation of presentation from content, or HTML STRICT.
As AutisticCuckoo said, if CSS 2.1 - the most recent version that is real-world deployable, wasn’t as lacking in capabilities we’d not need a lot of those extra wrappers… but that’s just the tip of the iceberg.
More importantly, DIV and SPAN are semantically neutral containers for WHEN there is no better semantic tag but you still need to target it. We would either need to not apply styling the developer may want to just because we have no perfectly matched-up meaning, abuse existing tags (like the jokers wrapping DL’s around LABELS and INPUTS), or worst of all require dozens more semantic tags to even scratch the surface of what we need to do turning the specification into a bloated mess like HTML5 is trying to do. When people can’t even bother learning how to use numbered headings or tags like LEGEND, FIELDSET, TH, CAPTION or LABEL, or even make the distinction between a presentational image and a content image – adding more tags to the specification is not the answer when people can’t even keep the difference between an abbreviation and an acronym straight. (that some jackass started saying it was ok to put some acronyms in as abbreviations didn’t help, much less the abuse of the tag by the microformats nutzo’s)
That’s really the most important part about those tags and why it’s ok to use them as hooks; Semantic neutrality. They apply NO NEW MEANING to any content they surround… so when styling is off they have NO effect. That’s a good thing and the reason to use them.
One detail of semantics people constantly miss: It’s not just about slapping meaningful containers around content, it’s also knowing when NOT to slap containers with meanings around the WRONG content. Again, you see a definition list around labels and inputs (or worse with no labels at all), paragraphs around lone image tags, paragraphs around a two word blob of text that’s not part of an article or even paragraph tags around text inside a LI; That’s not semantic markup, that’s tag abuse.
For example, if you had a image plate with associated text, the border and float you apply to both for screen is NOT part of the content, but you still need a hook to wrap both. DIV allows you to do so without changing their meaning – since it doesn’t imply a meaning to them, it’s still semantic while giving you your hook.
Back to rounded corners, you need two elements to do a sliding doors before it; what are you going to use to do it? You can’t do it without the extra elements – so you use elements that apply no extra meaning to the page PRESERVING your semantic markup without implying any extra meaning.
While presentational tags, the ones removed in strict like FONT, CENTER, etc, imply a meaning, or at least an appearance.
That I think is what you are failing to grasp; DIV and SPAN all on their own, apart from DIV being block-level applies NO meaning OR appearance to the content it wraps. PERIOD. Which means that with media types you can use that hook to say “left” for screen, “centered” for handheld and “right” for print. That is what the separation of presentation from content and deprecation of presentational tags is about.
It’s NOT to get rid of presentational HOOKS, it’s to get rid of PRESENTATION. There’s a difference. You still need the hooks to apply CSS TO. You just want those hooks NOT to say all by themselves what that presentation actually IS.
Part of why I consider presentational classnames like “left”, “smalltext” or “width960” to be as big a steaming pile of /FAIL/ as still using HTML 3.2… or a tranny doctype for that matter… Since I suddenly want to be able to have my back-end switch from RTL to LTR capability I don’t want to have to go through and change every “left” to “right” in the markup when I could just change the CSS and leave the markup alone… or to reskin from a fixed 960 width to semi-fluid or totally fluid.
Markup is for saying what things are, and any hooks you need to apply styling (and IMHO WHY/WHAT), CSS is for saying what that appearance actually IS.
A DIV with a class on it doesn’t actually apply appearance, the CSS does; and the CSS can apply any appearance to it - so it has no impact on the semantics of the rest of the page or on it’s appearance when CSS is not present if you use them properly or in a logical fashion. Same actually goes for empty tags - if there’s no content, there’s nothing for the tag to apply meaning to, letting you often squeeze in some appearance without resorting to bloating out the markup and CSS with more classes. (see the use of B or I, which also apply no semantic meaning unlike STRONG and EM)
XHTML, at least in the 1.0 version (the only real world deployable one) simply exists to map the HTML 4 specification to a XML namespace. There is no reason for neutral tags to have any effect on if it’s valid XML or not; well, unless you get inline-level and block-level confused and end up with a malformed document. (which people who forget the difference and which tags are which do screw up all the time).
Simply using div’s, even empty ones, has no impact on if it’s valid XML or not; NOR would it EVER have an impact on XHTML 1.0
Now 1.1, that’s a different story, but given the total disaster that turned into and that the whole ‘XML application’ garbage doesn’t do anything I’d want to see done on a web page, who cares?
If you’re gonna rage every time you see a DIV or SPAN used as a presentational hook in a strict document, you not only missed the point of STRICT, you aren’t going to get very far as a developer.
The point being, DIV does not apply presentation (apart from the block level behavior, which does nothing if it’s surrounded by other block level containers or the content is in other block level containers like headings or P) – CSS does. It implies no meaning whatsoever to the content it wraps in and of itself. As such, the presentation is not in the markup no matter how many DIV you use.
Unlike say… CENTER, FONT, STRIKE, UNDERLINE
Though I would also point out that STRICT is NOT just about removing presentation - that’s not it’s entire focus even though many people falsely claim it is - it’s just PART of it.
Look at some of the other tags and attributes deprecated: iframe, frameset, frames, noframes, target – that’s all accessibility related since those are a miserable accessibility /FAIL/ - as such you shouldn’t be using any of them. Frames not only didn’t work in less capable browsers or be handled well by things like screen readers, how do you link someone to the content of a frame; by hiding the URL it prevented content linking (see why AJAX tabs are a accessibility train wreck), they are easily abused for cross site exploits… and things like TARGET let you override the default behavior of a anchor and even normal site navigation; see target=“_blank” – one shouldn’t be shoving opening a window down the users throat, they want it in a new window they can middle click. (well, unless they’re one of those one button mouse whackos, in which case hit shift while clicking)
How about DIR and MENU? Redundant to UL… APPLET? redundant to OBJECT. The whole idea of removing those was to reduce the number of tags in the hope that with less tags developers could write cleaner code or at least start paying attention to the ones that remain… again something HTML5 seems to be in favor of completely undoing. (CANVAS, EMBED, VIDEO and AUDIO all being redundant to OBJECT, and of course they brought menu back for god only knows what on form elements instead of for use on SHOCK menus… NO, for that they have NAV)
I really think you missed the point of STRICT, but then it often feels like the number of people who seem to have gotten it can be counted on one hand. Half of them have already posted in this thread… Now we just need Alex, Paul O’B and the Stupid Dutch Kitty to chime in and we’ll have the superfecta. Though I think a lot of the misunderstanding can be blamed on the specification being written in such a convoluted legalese that a good lawyer could probably make it say anything he wanted to a jury. Hardly a wonder even the browser makers can’t all agree on what the specifications actually SAY. (much less how to handle the stuff it doesn’t even mention that it SHOULD)
Ah, were that Dan was still with us… he was much more eloquent at explaining this stuff.
what stands between strict and transitional is the separation of content from presentation. this has lead towards the deprecation of some elements. not the other way around, which is that the deprecation of some elements has given birth to strict. not using those deprecated elements is not the only single rule that is going to make a strict out of a transitional.
so if you are using elements for presentational feats only, that have nothing whatsoever to do with the structure or the presentation of the actual content (no matter what elements are those), your document may validate as strict (and that can happen also with a lot of openly declared transitional documents), but it really means transitional. it’s (hopefully) still looking for a way to ditch those elements used only for presentation outside the content point of view. so why lie? why deprave strict’s good name?
this misunderstanding and misuse i believe has had a bad influence over the current html5 draft.
i hope not to upset you, but i think that ie is possible to have been right when chose not to support xhtml.
they did a smarter thing though: they allowed xml islands. and kept html clean. parsing their (xml islands) content could have been done also by a plug-in, to handle easily complex uses.
take a look at this scenario: if all browsers would have supported <xml> tag, many wrong uses for xhtml could have been avoided, and semantics spared. the same thing if ie would have supported xhtml, but still having all these problems concerning semantics.
given the existing situation, one possible scenario would be the following:
- use xml islands for ie
- use xhtml for the the rest, but only to allow an <xml> element
all your data, described by microformats or by a personal DTD, should go inside these type of elements. it would make much more sense.
i don’t see ie stopping you though 
ok, don’t like japanese? maybe dutch is your thing then? but i thought that there every town can have it’s own little language.
don’t you see that’s not the point of x(ht)ml? it’s only one of it’s possible uses, and not even the smartest one.
who’s stopping them to use japanese for their xhtml tags?
Internet Exploder.
needs to be correlated with some way of rendering, other that a DTD and CSS, in order to make sense to everybody. you’re using <streetaddress>Hondenpoeplaan 5</streetaddress> and hope that 60-80% off all the people reading it would understand basic english
Yes did you not realise that’s the point of XHTML? You would indeed have to make your own DTD if you are using your own tags. And basic English has nothing to do with it. What kinds of tags do you think Japanese pages use?
sorry, errata:
<span class=“city”>Paris</city>
is in fact
<span class=“city”>Paris</span>
and no, flash it’s not a x(ht)ml 
i was just in a hurry to make a point while having somebody standing behind me 
maybe i’m not seeing it right. xhtml expands the language not the vocabulary.
an example: <span class=“city”>Paris</city> is the expansion of vocabulary, like <noun class=“city”>Paris</noun> would be for the human language. doing <city>Paris</city> it’s like creating new language elements for each word you like. and doing so, the language elements would surpase in number the actual words used in a language. how would you be able then to make sense of the grammar of a language? html is for displaying the info. xhtml wrongly understood uses html as grounds for data exchange, when it’s supposed to enrich the way data is presented, instead.
xhtml used for <city> adds new language elements that have no general semantic meaning, only locally declared meaning. how many specs would invade the web, trying to keep track of everybody’s imagination. and how much redundancy would cause that?
this use:
needs to be correlated with some way of rendering, other that a DTD and CSS, in order to make sense to everybody. you’re using <streetaddress>Hondenpoeplaan 5</streetaddress> and hope that 60-80% off all the people reading it would understand basic english. when changed to <عنوان الشارع>Hondenpoeplaan 5</عنوان الشارع> then this would drastically change your view on the extensibility of xhtml.
these (DTD and CSS) are the easy way to go. we need standardized ways for xhtml. like svg, or flash. that’s why a plug-in for this make more sense, keeping it out from clouding the html markup.
I’ll add comment to that lower down, where you call me out by name.
Yes, they ‘know’ what an
<address>is. That’s how they know how to treat it, i.e., render it.
No they don’t. Without a style sheet, or cfg file, whether built in or separate, the UA has not a clue. The entire document would render as an inline string.
Should we then, in your opinion, use only
<div>and<span>, since the browser doesn’t have to know what elements are?
Of course not. Those element and attribute tokens are used to build a DOM structure which the stylesheet, client script, or other application uses to render visually, aurally, or as in an earlier example, turn on the coffee maker.
Precisely. And I don’t know why people seem to forget about other user agents and believe that the Web is only about graphic browsers.
Yeah, what I said.
Of course not. But
classattributes aren’t meaningful to the user agent, while element type names are. Microformats are a way to present basic semantic information to general-purpose UAs, e.g., ‘this is a span of characters’, while at the same time passing more details to specialised UAs, e.g., ‘this is the city name as part of a postal address’.
Using new element types, like <city>, you would lose all semantics in the former case.
Microformats are a way to present basic semantic information to general-purpose UAs, […] while at the same time passing more details to specialised UAs, […]. Exactly, as a kluge to counter the lack of xhtml support by the majority browser. Their time and efforts would certainly have been better spent developing standardized xhtml+xml schemata, but that was impossible.
Oh, so you too think that a web documents is just a pretty picture? Et tu, Gary?
No, Tommy, I think the web document is one with markup that tells the user just what the content is. The user might be me and my Iceweasel sitting at my desk reading these comments, or might be my hypothetical coffee maker, or a screen reader application. In every case, there are instructions for what to do with the content: make this font 24px, make that element float right, make that word louder, use 113ml of water, 40g of coffee, and start brewing at 0630.
XHTML allows the author to expand the vocabulary and define its relationships within the structure, making for a finer granularity of meanings. There is no way that is less semantic or useful than the Microformat scheme. I can easily imagine incorporating many of the class tokens into an xhtml extension, and the work of the wg is not wasted. There was much thought put into Microformat that is readily transferable to xhtml if MSFT gets off their collective ass and makes it work for IE (and it’s not so late that developers have completely given up, or are overly vested in Microformat parsers). Each time I go to Allsopp’s book, I am knocked over anew by some little something that manages to make the whole concept that much more robust, something I would likely have missed.
cheers,
gary
Well, not if you think a web page is a pretty picture to look at. But I thought more of you than that, Poes!
The only thing a browser knows about most elements is how to render it. It does not actually extract meaning from them. An application could though. I don’t really see what pictures have to do with anything??
Yes, they ‘know’ what an <address> is. That’s how they know how to treat it, i.e., render it.
But they don’t know it’s an address. Was kinda the whole point of the microformats… the browser still doesn’t know it’s an address, but someone’s goofy PDA reading the page does, and is able to take the stuff inside and shove it appropriately into its addressbook.
If we told the application what <city> was, and <street>, then after grabbing from the dumb browser, it could not only place the city in the proper “city” section, but now you can look up people in your addressbook by city.
Or whatever, I’m not really hip enough to get enthousiastic with the whole “real XHTML/microformats” stuff, but I understand what they want to accomplish.
Should we then, in your opinion, use only <div> and <span>, since the browser doesn’t have to know what elements are?
That only gives you two options of information. Gary mentioned extensibility of XHTML. I never thought that had anything to do with browsers actually learning the meaning of anything (it’s still going to see things as blocks, inlines, whatever you or the vendor tells it).
Using new element types, like <city>, you would lose all semantics in the former case.
Whether we’re talking about Gary’s <city> within a real XHTML page (with its own DTD) or a microformat bloat like <span class=“city”>, the semantics are the same (aren’t they? If not, why not?). One looks cleaner. The other makes overuse of spans and divs and class attributes.
<address>
<span class=“name”>Joe</span>
<span class=“streetaddress”>Hondenpoeplaan 5</span>
<span class=“postalcode”>1234 GG </span>
<span class=“city”>Borculo</span>
<span class=“country”>People’s Republic of Foo</span>
</address>
Or
<address>
<name>Joe</name>
<streetaddress>Hondenpoeplaan 5</streetaddress>
<postalcode>1234 GG</postalcode>
<city>Borculo</city>
<country>People’s Republic of Foo</country>
</address>
It’s no dream of mine, but again, I can see why people want it.
precisely my point: Japanese pages use html tags. who’s stopping them to use japanese for their xhtml tags? would then basic english have something to do with you, a japanese illiterate?