What I'm trying to do is remove the drop down arrow from a select with this CSS:
.Gender:first-child::-ms-expand {
display: none;
}
The select element is disabled and its content is set programmatically. It is still a select because of our "unique" roll-your-own binding approach that would be a huge overhaul to replace/update.
Basically I have a section to input basic information for a dynamic number of people. The first instance is always the Primary instance and it's data comes from another section of the page so it's disabled here and bound to the values in that other form. Every other entry after it is editable. The idea was to remove the drop down arrow from the first selects because they're read only. I know that even though the drop down arrow is missing that the select continues to work but I still want it to be there for every other select that isn't disabled.
I know it works in a simplified JSFiddle but in my site ALL selects that have those classes are hiding their drop down arrow. What can I look for in my site that would circumvent the :first-child pseudo class? Why could it possibly work in the fiddle but not in the actual site?
Everything I'm reading says to check your doctype. Mine is <!DOCTYPE html public "-//W3C//DTD HTML 4.0 Transitional//en">. Nobody that I found ever explicitly says the exact doctype to use, so this may not be 100% correct.
Also, this only needs to work in IE10, it's an internal web app that'll never be run anywhere else.
The single most common cause of every instance of a specific element matching :first-child, when only the first of them should match, is if each of those elements actually exists in its own container element. Here's an example:
<div class='parent'>
<select class='Gender'>
<option>Male</option>
<option>Female</option>
</select>
</div>
<div class='parent'>
<select class='Gender'>
<option>Male</option>
<option>Female</option>
</select>
</div>
<div class='parent'>
<select class='Gender'>
<option>Male</option>
<option>Female</option>
</select>
</div>
Here, every .Gender is the first — and only — child of its parent element, .parent. The .parent elements themselves, on the other hand, are siblings of one another, sharing the same parent element (not shown). Depending on what your source looks like, it may be difficult to pinpoint the location of these parent elements within the source, but as long as your markup is valid, they should be somewhere.
If it does turn out to be the problem, fixing it is trivial — just move the :first-child pseudo-class to the appropriate element:
.parent:first-child .Gender::-ms-expand {
display: none;
}
Updated fiddle
Related
This is a question regarding Angular 2 selectors, Custom tags vs. Custom attributes, SEO and browser rendering.
When I first started to look over Angular 2, the very first thing I did when following their quickstart, right of the bat, was to change my selector to '[my-component]' (attribute selector) instead of 'my-component' (tag selector), so I could have <div my-component></div> in my html instead of <my-component></my-component>, which isn't valid html. So I would write html according to standards. Well, at least pretty close to standards (because my-component isn't a valid html attribute, but I could live with only that html validation error)
Then, at some point in a video on youtube, someone from the angular team mentioned that we should use the tag selector, performance wise at least.
Alright I said, screw html validation... or shouldn't I?
So:
Say I ignore the W3C screaming about my html being completely invalid because of the <custom-tags>. I actually have another bigger and more real concern: how does this impact SEO?
I mean don't just think client-side app, because in the real world (and for my angular 2 project as well) I also have server-side rendering, for 2 very important reasons: SEO and Fast initial rendering of the site to the user for that initial view, before the app bootstraps. You can not have a very high traffic SPA otherwise.
Sure, google will crawl my site, regardless of the tags I use, but will it rank it the same in both scenarios: one with <custom-make-believe-tags> and the other with only standard html tags?
Let's talk browsers and css:
As I started to build my first SPA site in Angular 2, I was immediately faced with another concern:
Say (in a non SPA site) I have the following html markup:
<header>
<a class="logo">
...
</a>
<div class="widgets">
<form class="frm-quicksearch"> ... </form>
<div class="dropdown">
<!-- a user dropdown menu here -->
</div>
</div>
</header>
<div class="video-listing">
<div class="video-item"> ... </div>
<div class="video-item"> ... </div>
...
</div>
Angular 2 wise I would have the following component tree:
<header-component>
<logo-component></logo-component>
<widgets-component>
<quicksearch-component></quicksearch-component>
<dropdown-component></dropdown-component>
</widgets-component>
</header-component>
<video-listing-component>
<video-item-component></video-item-component>
...
</video-listing-component>
Now, I have 2 options. Let's just take the <video-listing-component> for example, to keep this simple... I either
A) place the entire standard html tags which I already have (<div class="video-item"></div>) within the <video-item-component> tag, and once rendered will result in this:
<video-listing-component>
<div class="video-listing>
<video-item-component>
<div class="video-item>...</div>
</video-item-component>
...
...
</div>
</video-listing-component>
OR:
B) Only put the content of <div class="video-item"> directly into my <video-item-component> component and adding the required class (class="video-item") for styling on the component tag, resulting in something like this:
<video-listing-component class="video-listing">
<video-item-component class="video-item"></video-item-component>
<video-item-component class="video-item"></video-item-component>
...
</video-listing-component>
Either way (A or B), the browser renders everything just fine.
BUT if you take a closer look (after everything is rendered in the dom, of course), by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I don't get it how come the browser still renders everything as you would want to see it, I mean in the first case (A):
While having float: left; width: 25%; on the div class="video-item", but each of these divs being within a <video-item-component> tag, which doesn't have any styling... Isn't it just a fortunate side-effect that the browser renders everything as you'd expect? With all the <div class="video-item"> floating next to eachother, even though each of them are within another tag, the <video-item-component> which does NOT have float: left? I've tested on IE10+, Firefox, Chrome, all fine. Is it just fortunate or is there a solid explanation for this and we can safely rely for this kind of markup to be rendered as we'd expect by all (or at least most) browsers?
Second case (B):
If we use classes and styling directly on the custom tags (<video-item-component>)... again, everything shows up fine. But as far as I know, we shouldn't style custom components, right? Isn't this also just a fortunate expected outcome? Or is this fine also? I don't know, maybe I'm still living in 2009... am I?
Which of these 2 approaches (A or B) would be the recommended one? Or are both just fine?
I have no ideea!!
EDIT:
D'oh, thanks Günter Zöchbauer. Yeah, since my divs have float: left, that's why the (custom or not) tag they're wrapped in doesn't expand it's height. Seems I've forgotten how css works since I started to look over Angular 2:)
But one thing still remains:
If I set a percentage width on a block element (call it E), I would assume it takes x% of it's immediate parent. If I set float: left, I would expect floating within the immediate parent. In my A case, since the immediate parent is a custom tag with no display type and no width, I would expect for things to break somehow, but still... my E elements behave like their parent isn't the custom tag they're each wrapped in, but the next one in the dom (which is <div class="video-listing> in my case). And they occupy x% of that and they float within that. I don't expect this to be normal, I would think this is just a fortunate effect, and I'm afraid that one day, after some browser update... I'll wake up to find all my Angular 2 sites looking completely broken.
So... are both A and B an equally proper approach? Or am I doing it wrong in case A?
EDIT2:
Let's simplify things a bit. As I got part of my question answered, let's take another example of generated html (simplified a bit, with inlined css):
<footer>
<angular-component-left>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-left>
<angular-component-right>
<div style="float: left; width: 50%;">
DIV CONTENT
</div>
</angular-component-right>
</footer>
In the original, not yet implemented html (whithout <angular-component-...>, those divs should float left and each occupy 50% of the <footer>. Surprisingly, once they're wrapped in the <angular-component-...> custom tags, they do the same: occupy 50% of the footer. But this just seems like good fortune to me, dumb luck... Unintended effect.
So, is it or isn't it "dumb luck"?
Should I leave it like that, or rewrite so instead of the above code, I would have something like this:
<footer>
<angular-component-left style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-left>
<angular-component-right style="display: block; float: left; width: 50%;">
DIV CONTENT
</angular-component-right>
</footer>
Note that the inline styling is introduced here for simplicity, I would actually have a class instead which would be in an external css file included in the <head> of my document, not through style or styleUrls from my angular components.
The issue is your HTML validator. The - in the element name is required for elements to be treated as custom elements and it is valid HTML5. Angular doesn't require - in element names but it's good practice.
Check for example https://www.w3.org/TR/custom-elements/#registering-custom-elements (search for x-foo) or https://w3c.github.io/webcomponents/spec/custom/#custom-elements-custom-tag-example. I'm sure this dash rule is specified somewhere but wasn't able to find the spec. It is for example required in Polymer that depends on elements being proper custom elements while this doesn't matter much in Angular. The only difference as far as I know is that when you query the element, you get a HTMLUnknownElement when the - is missing in the name and a HTMLElement when it contains a -.
See also this question I asked a few years ago Why does Angular not need a dash in component name
BUT if you take a closer look, by default the custom tags don't occupy any space in the dom. They're 0px by 0px. Only their content occupies space. I just don't get it how come the browser still renders everything as you would want to see it
I'm not sure I understand this question. When Angular processes the template it adds the content dynamically. When you see the content in the browser than it's also available in the DOM and has actual dimensions.
Search engine crawlers are able to process pages that are generated by JavaScript. If this isn't enough, server-side rendered pages can provide static HTML to crawlers that contain the whole view.
I'd like to implement a listbox widget using the current web components specs. Moreover, the resulting listbox should conform to the ARIA standard. Instantiating the listbox widget should be as simple as:
<x-listbox>
<x-option>Option 1</x-option>
<x-option>Option 2</x-option>
</x-listbox>
For purposes of cleanliness and encapsulation, everything else should be rendered in shadow dom. To implement this widget, two custom elements, <x-listbox> and <x-option> are registered. The top-level element of the shadow dom of <x-listbox> is a <div> that carries the role=listbox and the aria-activedescendent attributes for accessibility (I don't want these attributes on the <x-listbox> element because they are implementation details.)
In order for aria-activedescendent to work, one needs ids on the option elements. Putting ids directly on the <x-option> elements won't work out of two reasons: Firstly, it would pollute the id namespace of the document that uses the listbox widget. Secondly and even more importantly, ids do not work across shadow boundaries (which is one purpose of the shadow dom), so the ids of the options have to live in the same shadow dom as the <div> with the aria-activedescendent attribute.
A solution for this would be to surround each <x-option> that is rendered as content inside the shadow dom of <x-listbox> with another <div> (belonging to that shadow dom), on which an id can be put.
My question is: Is this the right way to go and how to implement this using the custom element and shadow dom web apis?
Your probably should better implement this by creating an select element (using JavaScript). This should ensure screen readers recognize this correctly as an input for selecting a value/values from a list.
Add an select element like this below your <x-listbox> element:
<select class="only-screenreader">
<option>Option 1</option>
<option>Option 2</option>
</select>
Then add aria-hidden="true" to your custom <x-listbox> element.
Finally apply CSS to make the screenreader select element invisible.
.only-screenreader {
position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;
}
That's my approach but maybe there's a better one.
In the markup provided, x-option is in the light DOM, not the shadow DOM, so it can be referred to by id. To avoid polluting the id namespace, I generate a random id, which is set when the component loads but can be replaced. This way I can refer to the element by id whether or not the component user has set an id on it.
Wrapping each option in a div seems unnecessary and likely to cause issues. Also, if the options are in a <slot />, it's simply not possible.
I would like to use css3 features to hiding previous element.
Basically,
I want to use a checkbox to hide previous sibling element without using javascript.
I have prepared a sample for entry point.
http://cssdesk.com/5zccy
Thanks
Edit:
I have changed sample.
My usecase: I want to have collapsible sections at my site. Two area separated by a simple checkbox and checking it will beautifully hide previous sibling.
I believe that using pure css will let me to reduce using javascript for this task.
You can not hide the previous elements - just the following ones with the general sibling selector
DEMO
Then you might be able to position the elements, so on the actual page the checkbox will appear after the .parent div.
There's no css selector to select the previous tag of a matched element. The closest you can get using only css it's doing that for the next element:
<input class="hider" type="checkbox" /> child
<div class="parent">
Parent
</div>
.hider:checked + * {
display:none;
}
Normally CSS is my thing, but I'm somehow dumbfounded why this isn't working for me. I'm building a site through Cargo for CMS purposes and you can see it here: http://cargocollective.com/mikeballard
In my menu, I have five main categories, and clicking on them (images, for example) reveals the list of work under that category.
<div id="menu_2444167" class="link_link">
<a id="p2444167" name="mikeballard" target="" href="http://cargocollective.com/mikeballard/filter/images">Images</a>
</div>
<div id="menu_2444188" class="project_link">
<a name="mikeballard" rel="history" href="mikeballard/#2444188/Ultra-Nomadic-Def-Smith-Cycle-2011">Ultra Nomadic Def Smith Cycle, 2011</a>
</div>
<!-- more divs here -->
<div id="menu_2444201" class="project_link">
<a name="mikeballard" rel="history" href="mikeballard/#2444201/Archive">Archive</a>
</div>
Basically, I'm trying to select the last div in this set, and add a margin-bottom:15px to that div. I've tried using:
.project_link:last-child or .project_link:last-of-type but it doesn't seem to be working.
The HTML, which can't be altered too much to rely on Cargo, isn't great as if they had used list items, instead of divs with anchor tags I'm assuming this would be a lot easier.
The :last-of-type and :last-child selectors are not supported before IE9.
Class names, etc are not looked at when it comes to the :last-child and :last-of-type selectors. The .project_link:last-child selector will only trigger if the specific element is the last child in the parent element and has the class "project_link", and the .project_link:last-of-type selector will only trigger if the specific element is the last element of that type and has the class "project_link".
Both should trigger in a supporting browser, since it is implied as *.project_link:last-of-type and will check for every type of element inside that parent (which appears to only be divisions anyways). The last division shown here has the class "project_link" which would match this rule. The only reason these wouldn't trigger is if you had extra elements (or divisions) below what you're showing us, or you're using a browser which doesn't support it.
assuming i have few items with similar ids:
<input class="a" id="id_1"/>
<input class="a" id="id_2"/>
i would like to set in my css file something like:
#id_*{width = 100%;}
is there a way i can do that?
i've tried something like:
input[id^='id_']{width:200px;}
but that didnt worked out......
And its need to work on IE :(
EDIT: nedd to work on IE8....
EDIT:
<input tabIndex="1690" class="form" id="cust_1_NUM_OBJ_5-00461" dataFld="cust_1_NUM_OBJ_5-00461" dataSrc="#FIELDVALUES" style="text-align: right; height: 20px;" onkeypress="validateNumberChar(this)" onfocus="resetGFocusField('cust_1_NUM_OBJ_5-00461');" onblur="validateChangedNumber(this);" onbeforedeactivate="onbeforedeactivateLookup(this);" type="text" size="20" maxLength="55" datatype="number" numbertype="24,6" valueFieldID="null" tabStop="true" value="1"/>
and CSS:
input[id^='cust_1_NUM_OBJ_5-0046']{width:200px;}
input[id^='id_']{width:200px;} should work. It certainly does in this fiddle:
http://jsfiddle.net/jYZnX/
EDIT: Also, to show that it doesn't pick an input without an id beginning 'id_':
http://jsfiddle.net/jYZnX/1/
EDIT 2: As your Document Mode seems to be set to Quirks this will cause issues with the css selector. Set your doc type correctly, eg using <!DOCTYPE HTML>. This will need access to the original code for the web pages though, so without that you will be in a spot of bother.
The selector you used (^), works correctly in IE:
input[id^='id'] {
background: red;
}
And here is the result:
IE7
IE8
IE9
IE10
As I saw in your pictures, your IE is rendering your page with Quirks Mode.
Maybe you have no doctype or wrong doctype at your page. Make your doctype valid as below:
<!doctype html>
My answer is quite general and never directly related to the question because this is already very old and so far solved by other answers on this page.
The first part of this answer is dry theory which is useful to understand the options.
The second part is an example for usage of this theory.
1) ATTRIBUTE SELCTORS
Substring matching attribute selectors:
[att^=val]
Represents an element with the att attribute whose value begins with the prefix "val". If "val" is the empty string then the selector does not represent anything.
[att$=val]
Represents an element with the att attribute whose value ends with the suffix "val". If "val" is the empty string then the selector does not represent anything.
[att*=val]
Represents an element with the att attribute whose value contains at least one instance of the substring "val". If "val" is the empty string then the selector does not represent anything.
Additionally there are still more selectors, in the specification they are sorted in the chapter Attribute presence and value selectors:
[att]
Represents an element with the att attribute, whatever the value of the attribute.
[att=val]
Represents an element with the att attribute whose value is exactly "val".
[att~=val]
Represents an element with the att attribute whose value is a whitespace-separated list of words, one of which is exactly "val". If "val" contains whitespace, it will never represent anything (since the words are separated by spaces). Also if "val" is the empty string, it will never represent anything.
[att|=val]
Represents an element with the att attribute, its value either being exactly "val" or beginning with "val" immediately followed by "-" (U+002D).
2) EXAMPLE HOW TO SELECT SEVERAL THINGS ON A PAGE DEPENDING ON AN EVENT
Wildcards are especially then useful when an event is triggered like that a page is visited with a special hash-tag. For a completely static page in contrast they are also useful but still could be noted different, even it would be more CSS-code.
Assume a page is visited with the hash-tag action, so the URL would look like this:
https://example.com/index.html#action
While only one id is triggered like that we can use it to note a whole stack of related actions in CSS, we just have to enclose the whole area where something shall happen in an element with the id action:
/* all div-elements which are direct child of element with class `wrapper` are hidden: */
.wrapper>div {
display: none;
}
/* following line addresses all elements inside element with the id "action"
where the id is starting with "action_". This is only triggered when the
URL with hashtag "action" is called, because of usage of ":target":
*/
#action:target [id^="action_"] {
display: block;
}
/* following line addresses all elements inside element with the id "amother-action"
where the class is "another-action". This is only triggered when the
URL with hashtag "another-action" is called, because of usage of ":target".
This example shows that we never need ids but can use classes too:
*/
#another-action:target .another-action {
display: block;
}
<div id="action">
<div id="another-action">
<div class="wrapper">
<!-- this small menu is always shown as it's an unordered list and no div: -->
<ul>
<li>No Action / Reset</li>
<li>Action</li>
<li>Another Action</li>
</ul>
<!-- The following div-elements are by default hidden and
only shown when some event is triggered: -->
<div id="action_1" class="another-action">
<!-- this is on both actions shown as the div has an id starting
with "action" and also a class "another-action" -->
Hello
</div>
<div id="action_2">
<!-- this is above only triggered by the CSS-rule
#action:target [id^="action_"] -->
World!
</div>
<div class="another-action">
<!-- This is above only triggered by the CSS-rule
#another-action:target .another-action -->
Everybody!
</div>
</div>
</div>
</div>
The different results are these:
When the page is called without any hash, only the menu is shown:
Action
Another Action
When the page is called with the hash action, below the menu can be seen:
Hello
World!
When the page is called with the hash another-action, below the menu can be seen this instead:
Hello
Everybody!
Like this we can mix much content where each division is only shown in special cases.
Mixing several ids and classes does only work if the elements with the ids are enclosing the elements with content and select-able properties. In my example above you can see that everything in HTML is written between <div id="action"><div id="another-action"> and </div></div>, like this every used event can optionally trigger everything in the content between.
Naturally it's possible by CSS to use this method for other effects too. Hiding or showing the elements is only a simple example but you could change colors, start CSS-animations and do many other things by CSS.
Keep care that you don't publish any confidential things in any of those elements, because this CSS-solution is no security but only for distinguishing cases for visual display.
Any things you hide or show like this are always visible in the HTML-source.
Given a three-column table with 200 rows and each row having an individual id like this row:
<tr id="row_177">
<td><a class="btn" href="..">Link1</a></td>
<td>Name of PDF File</td>
<td><select class="pdf_sel">
<option value=""> ---- </option>
<option>Crowell, Thomas</option>
</select>
</td>
</tr>
and given that you want to vertically center the content in each td, then the following css wildcard will cause the content of each td to be centered vertically** (I'm sure you could also use this to adjust width):
tr[id^='row_'] > td {
vertical-align:middle
}
** One caveat - the third column in the table contains a Select in each td. While the anchor button in the first column and the text anchor in the second column are centered vertically in each td by using the above css, the Select in the third column does not respond to this css for some reason - but there is a fix. The following css will cause the Select elements to be properly centered vertically:
tr[id^='pdfrow_'] > td > select {
margin-top:5px;
margin-bottom:5px
}
That is precisely what classes are for. What you want is:
.a { width: 100% }